oracle database 10g: data guard administration acle...

Oracle Database 10g: Data Guard Administration

Student Guide

D17316GC21

Edition 2.1

October 2008

D56312

®

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Copyright © 2008, Oracle. All rights reserved.

Disclaimer

This document contains proprietary information and is protected by copyright and other intellectual property laws. You may copy and print this document solely for your own use in an Oracle training course. The document may not be modified or altered in any way. Except where your use constitutes "fair use" under copyright law, you may not use, share, download, upload, copy, print, display, perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part without the express authorization of Oracle.

The information contained in this document is subject to change without notice. If you find any problems in the document, please report them in writing to: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not warranted to be error-free.

Restricted Rights Notice

If this documentation is delivered to the United States Government or anyone using the documentation on behalf of the United States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTSThe U.S. Government’s rights to use, modify, reproduce, release, perform, display, or disclose these training materials are restricted by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract.

Trademark Notice

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Author

Donna K. Keesling

Technical Contributors and Reviewers

Christopher D. AndrewsHarald van BreederodeLarry CarpenterMichael CebullaJoel Goodman

Editors

Arijit GhoshDaniel Milne

Graphic DesignerSatish Bettegowda

PublishersSrividya RameshkumarJobi Varghese

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Contents

Preface

1 Oracle Data Guard: Overview Objectives 1-2 Causes of Data Loss 1-3 Understanding the Causes of Downtime 1-4 What Is Oracle Data Guard? 1-5 Types of Standby Databases 1-6 Oracle Data Guard Broker Framework 1-7 Types of Services 1-8 Role Transitions: Switchover and Failover 1-9 Data Protection Modes 1-11 Benefits of Implementing Oracle Data Guard 1-13 Role of Data Guard in a High-Availability Architecture 1-14 Oracle Data Guard and Real Application Clusters 1-16 Maximum Availability Architecture 1-17 Summary 1-18 Practice 1: Overview 1-19

2 Understanding the Oracle Data Guard Architecture Objectives 2-2 Data Guard Operational Requirements: Hardware and Operating System 2-3 Data Guard Operational Requirements: Oracle Database Software 2-4 Oracle Data Guard: Architecture 2-6 Primary Database Flow 2-7 Standby Database Flow 2-8 Standby Redo Logs 2-9 Physical Standby Database: Redo Apply Architecture 2-10 Logical Standby Database: SQL Apply Architecture 2-12 SQL Apply Process: Architecture 2-13 Real-Time Apply 2-14 Setting the DB_UNIQUE_NAME Parameter 2-16 Specifying Role-Based Destinations 2-17 Combinations for VALID_FOR 2-19 Identifying Destination Settings 2-20

iii

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Standby Redo Log Configuration 2-21 Using SQL to Add Standby Redo Logs 2-22 Using Enterprise Manager to Add Standby Redo Logs 2-23 Standby Database Modes 2-24 Summary 2-26 Practice 2-1: Architecture Review 2-27 Practice 2-2: Installing the Oracle Management Agent 2-28 Practice 2-3: Configuring Your Primary Database 2-29

3 Using Data Guard Broker and Enterprise Manager Objectives 3-2 Features of Data Guard Broker 3-3 Data Guard Broker: Components 3-4 Data Guard Broker: Configurations 3-5 Data Guard Broker: Management Model 3-6 Data Guard Broker: Architecture 3-7 Life Cycle of a Broker Configuration 3-8 Data Guard Broker: Requirements 3-9 Data Guard Broker and the SPFILE 3-11 Data Guard Monitor: DMON Process 3-13 Data Guard Monitor: Configuration File 3-14 Benefits of Using the Data Guard Broker 3-15 Data Guard Broker Interfaces 3-17 Using Oracle Enterprise Manager 10g Grid Control 3-19 Data Guard Overview Page 3-20 Enterprise Manager Metrics and Alerts 3-21 Using Data Guard Metrics 3-22 Managing Data Guard Metrics 3-23 Benefits of Using Enterprise Manager 3-24 Using the Command-Line Interface of the Data Guard Broker 3-25 Summary 3-27

4 Creating a Configuration and Physical Standby Database by Using Enterprise Manager Objectives 4-2 Enabling FORCE LOGGING Mode 4-3 Using Enterprise Manager to Create a Broker Configuration 4-5 Creating a Configuration 4-6 Using the Add Standby Database Wizard 4-8 Step 1: Specify the Backup Type 4-9 Step 2: Specify the Backup Options 4-10

iv

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Step 3: Select the Standby Database Location Instance Name 4-11 Step 3: Select the Standby Database Location Oracle Home 4-12 Step 4: Specify the Standby Database File Locations Access Method 4-13 Step 4: Specify the Standby Database File Locations File Locations 4-14 Step 5: Specify Standby Database Configuration Parameters 4-15 Step 6: Review the Configuration Information 4-16 Standby Database Creation: Processing 4-17 Standby Database Creation: Progress 4-19 Standby Database Creation: Job Details 4-20 Verifying a Configuration 4-21 Reviewing Results of the Verify Operation 4-22 Creating Standby Redo Logs 4-23 Viewing the Data Guard Configuration Status 4-24 Viewing Data Guard Performance 4-25 Summary 4-26 Practice 4: Overview 4-27

5 Creating a Physical Standby Database by Using SQL Objectives 5-2 Steps to Create a Physical Standby Database 5-3 Preparing the Primary Database 5-4 Setting Initialization Parameters on the Primary Database 5-5 LOG_ARCHIVE_CONFIG 5-6 LOG_ARCHIVE_DEST_n 5-8 LOCATION and SERVICE Attributes 5-9 LOG_ARCHIVE_DEST_STATE_n 5-10 Specifying Values for DB_FILE_NAME_CONVERT 5-11 Specifying Values for LOG_FILE_NAME_CONVERT 5-12 Specifying a Value for LOG_ARCHIVE_FORMAT 5-13 Specifying a Value for STANDBY_FILE_MANAGEMENT 5-14 ARCHIVE_LAG_TARGET 5-15 LOG_ARCHIVE_TRACE Parameter 5-16 Example: Setting Initialization Parameters on the Primary Database 5-18 Backing Up the Primary Database by Using RMAN 5-19 Creating a Control File for the Standby Database 5-20 Copying Files to the Standby Database System 5-21 Oracle Managed Files (OMF) and Automatic Storage Management (ASM) 5-22 Setting Initialization Parameters on the Standby Database 5-23 Specifying a Value for STANDBY_ARCHIVE_DEST 5-25 Setting Up the Environment to Support the Standby Database 5-26

v

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Starting the Physical Standby Database 5-28 Additional Configuration Tasks 5-29 Special Note: Standby Database on the Same System 5-31 Summary 5-32

6 Configuring Data Protection Modes and Redo Transport Services Objectives 6-2 Data Protection Modes and Redo Transport Modes 6-3 Defining the Redo Transport Mode 6-4 Setting the Redo Transport Mode 6-6 Data Protection Modes 6-8 Maximum Protection 6-9 Maximum Availability 6-10 Maximum Performance 6-11 Setting the Data Protection Mode 6-12 Setting the Data Protection Mode by Using the CLI 6-14 Setting the Protection Mode by Using SQL 6-15 Delaying the Application of Redo 6-16 Using Enterprise Manager to Delay the Application of Redo 6-17 Setting LOG_ARCHIVE_DEST_n to Delay the Application of Redo 6-18 Using Flashback Database Instead of Apply Delay 6-19 Additional Attributes That Affect Redo Transport Services 6-20 Using the ALTERNATE Attribute 6-21 Using the MAX_FAILURE Attribute 6-22 Using the NET_TIMEOUT Attribute 6-23 Using the REOPEN Attribute 6-24 Optimized Asynchronous Redo Transmission 6-25 Enabling Multiple Connections for Remote Archival of Redo 6-26 Summary 6-27 Practice 6: Overview 6-28

7 Creating a Logical Standby Database by Using Enterprise Manager Objectives 7-2 Benefits of Implementing a Logical Standby Database 7-3 Securing Your Logical Standby Database 7-5 Preparing to Create a Logical Standby Database 7-6 Unsupported Objects 7-7 Unsupported Data Types 7-8 Checking for Tables with Unsupported Data Types 7-9 Unsupported DDL Commands 7-10

vi

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ensuring Unique Row Identifiers 7-11 Adding a Disabled Primary Key RELY Constraint 7-13 Supplemental Logging 7-14 Enabling Supplemental Logging 7-15 Verifying Values of Initialization Parameters 7-16 Creating a Logical Standby Database with Enterprise Manager 7-17 Using the Add Standby Database Wizard 7-18 Step 1: Specifying the Backup Type 7-19 Step 2: Specifying the Backup Options 7-20 Step 3: Selecting the Database Location Instance Name 7-21 Step 4: Specifying the Standby Database File Locations Access Method 7-22 Step 4: Specifying the Standby Database File Locations File Locations 7-23 Step 5: Specifying Standby Database Configuration Parameters 7-24 Step 6: Reviewing the Configuration Information 7-25 Standby Database Creation Processing 7-26 Automatic Deletion of Redo Log Files by SQL Apply 7-27 Enabling and Disabling the Auto-Delete Feature 7-28 Summary 7-29 Practice 7: Overview 7-30

8 Creating a Logical Standby Database by Using SQL Objectives 8-2 Preparing to Create a Logical Standby Database 8-3 Creating a Logical Standby Database 8-4 Step 1: Create a Physical Standby Database 8-5 Step 2: Stop Redo Apply on the Physical Standby Database 8-6 Step 3: Prepare the Primary Database to Support a Logical Standby Database 8-7 Step 4: Build a LogMiner Dictionary in the Redo Data 8-8 Step 5: Transition to a Logical Standby Database 8-9 Step 6: Open the Logical Standby Database 8-10 Step 7: Verify That the Logical Standby Database Is Performing Properly 8-11 Additional Configuration Tasks 8-13 Summary 8-14

9 Performing Switchover and Failover Objectives 9-2 Types of Roles in an Oracle Data Guard Configuration 9-3 Role Management Services 9-4 Role Transitions: Switchover and Failover 9-5 Choosing the Best Role Transition Operation 9-7 Switchover 9-8

vii

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Switchover: Before 9-9 Switchover: After 9-10 Standby Redo Logs and Switchovers 9-11 Preparing for a Switchover 9-12 Performing a Switchover by Using Enterprise Manager 9-13 Performing a Switchover to a Physical Standby by Using SQL 9-16 Performing a Switchover to a Logical Standby by Using SQL 9-18 Considerations When Performing a Switchover to a Logical Standby Database 9-23 Situations That Prevent a Switchover 9-24 Failover 9-25 Failover Considerations 9-26 Performing a Failover by Using Enterprise Manager 9-27 Performing a Failover to a Physical Standby Database 9-31 Performing a Failover to a Logical Standby Database 9-32 Performing a Failover to a Physical Standby Database by Using SQL 9-33 Performing a Failover to a Logical Standby Database by Using SQL 9-36 Activating a Standby Database 9-38 Restoring Databases After a Role Transition 9-39 Flashback Through Standby Database Role Transitions 9-40 Using Flashback Database After Failover 9-41 Summary 9-44 Practice 9: Overview 9-45

10 Enabling Fast-Start Failover Objectives 10-2 Fast-Start Failover: Overview 10-3 When Will Fast-Start Failover Occur? 10-4 Installing the Observer 10-5 Configuring Fast-Start Failover 10-6 Step 1: Specifying the Target Standby Database 10-7 Step 2: Setting the Fast-Start Failover Threshold 10-8 Step 3: Enabling Fast-Start Failover 10-9 Step 4: Starting the Observer 10-10 Step 5: Verifying the Configuration 10-12 Viewing Information 10-13 Prohibited Operations After Enabling Fast-Start Failover 10-15 Disabling Fast-Start Failover 10-16 Using the FORCE Option 10-18 Stopping the Observer 10-19 Performing Role Changes 10-20 Performing a Manual Failover 10-21

viii

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Automatic Reinstatement After Fast-Start Failover 10-22 Manually Reinstating the Database 10-24 Using Enterprise Manager to Enable Fast-Start Failover 10-25 Changing the Protection Mode and Disabling Fast-Start Failover 10-31 Using Enterprise Manager to Disable Fast-Start Failover 10-32 Using Enterprise Manager to Suspend Fast-Start Failover 10-33 Summary 10-34 Practice 10: Overview 10-35

11 Using Data Guard in a Real Application Clusters Configuration

Objectives 11-2 Real Application Clusters and Data Guard 11-3 Configuration Considerations with RAC 11-4 Multi-Instance Primary Database with a Single-Instance Standby Database 11-6 Multi-Instance Primary Database with a Multi-Instance Standby Database 11-7 Redo Transport with RAC to RAC 11-8 Setting Up a Primary Database with RAC 11-9 Setting Up a Standby Database with RAC 11-10 Assigning Threads to Standby Redo Log Groups 11-11 Apply Instance Failover 11-12 Role Transitions with RAC 11-14 Troubleshooting 11-15 Summary 11-17

12 Other Considerations for Oracle Data Guard

Objectives 12-2 Offloading Backups to a Physical Standby 12-3 Using RMAN to Back Up a Physical Standby Database 12-4 Restrictions and Usage Notes 12-5 Backup and Recovery of a Logical Standby Database 12-6 Flashback Across Database Changes 12-7 Using Flashback Database and Real-Time Apply 12-8 Using Flashback Database After RESETLOGS 12-9 Enabling Redo Encryption 12-11 Activating a Physical Standby Database for Reporting 12-12 Cascaded Redo Log Destinations 12-15 Configuring Cascaded Redo Log Destinations: Physical Standby 12-16 Role Transitions with Cascaded Redo Log Destinations 12-18 Summary 12-19

ix

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

13 Workshop Objectives 13-2 Workshop Premise 13-3 Workshop Flow 13-4 Workshop Scenarios 13-5 Summary 13-8

Appendix A: Practices and Solutions

x

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Preface

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Preface - 3

ProfileBefore You Begin This Course

Before you begin this course, you should have the following qualifications:Thorough knowledge of Oracle Database 10gWorking experience with Oracle Database 10g and Oracle Enterprise Manager Grid Control

Prerequisites:Oracle Database 10g: Administration Workshop I (D17090GC30)Oracle Database 10g: Administration Workshop II (D17092GC30)Suggested: Oracle Enterprise Manager 10g Grid Control Release2 (D17244GC20).

How This Course Is OrganizedOracle Database 10g: Data Guard Administration is an instructor-led course featuring lectures and hands-on exercises. Online demonstrations and written practice sessions reinforce the concepts and skills that are introduced.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Preface - 4

Related PublicationsOracle Publications

Title Part NumberOracle Database Administrator's Guide 10g Release 2 (10.2) B14231-02Oracle Database Concepts 10g Release 2 (10.2) B14220-02Oracle Database Performance Tuning Guide 10g Release 2 (10.2) B14211-01Oracle Database Reference 10g Release 2 (10.2) B14237-02Oracle Database SQL Reference 10g Release 2 (10.2) B14200-02Oracle Database Utilities 10g Release 2 (10.2) B14215-01Oracle Data Guard Broker 10g Release 2 (10.2) B14230-02Oracle Data Guard Concepts and Administration 10g Release 2 (10.2) B14239-04

Additional Publications• System release bulletins• Installation and user’s guides• read.me files• International Oracle User’s Group (IOUG) articles• Oracle Magazine

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Preface - 5

Typographic ConventionsWhat follows are two lists of typographical conventions that are used specifically within text or within code.Typographic Conventions Within Text

Convention Object or Term Example

Uppercase Commands, Use the SELECT command to viewfunctions, information stored in the LAST_NAMEcolumn names, column of the EMPLOYEES table.table names,PL/SQL objects,schemas

Lowercase, Filenames, where: role is the name of the role italic syntax variables, to be created.

usernames,passwords

Initial cap Trigger and Assign a When-Validate-Item trigger tobutton names the ORD block.

Choose Cancel.

Italic Books, names of For more information on the subject seecourses and Oracle SQL Referencemanuals, and Manualemphasized words or phrases Do not save changes to the database.

Quotation marks Lesson module This subject is covered in Lesson 3,titles referenced “Working with Objects.”within a course

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Preface - 6

Typographic Conventions (continued)Typographic Conventions Within Code

Convention Object or Term Example

Uppercase Commands, SELECT employee_idfunctions FROM employees;

Lowercase, Syntax variables CREATE ROLE role;italic

Initial cap Forms triggers Form module: ORDTrigger level: S_ITEM.QUANTITYitemTrigger name: When-Validate-Item. . .

Lowercase Column names, . . .table names, OG_ACTIVATE_LAYERfilenames, (OG_GET_LAYER ('prod_pie_layer'))PL/SQL objects . . .

SELECT last_nameFROM employees;

Bold Text that must CREATE USER scottbe entered by a IDENTIFIED BY tiger;user

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Oracle Data Guard: Overview

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Oracle Database 10g: Data Guard Administration 1 - 2


Objectives

After completing this lesson, you should be able to do the following:• Describe the factors that affect planned and unplanned

downtime• Describe the basic components of Oracle Data Guard• Explain the differences between physical and logical

standby databases• Explain the benefits of creating a Data Guard

environment• Explain the use of Data Guard in high-availability

architectures

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Causes of Data Loss

Source: Disaster Recovery Journal

Natural disasters 3%

Software corruption 4%

Computer viruses 7%

Human errors 36%

Hardware & system errors 49%

Causes of Data LossAccording to a survey published in the Disaster Recovery Journal (DRJ), the leading causes of data loss were not natural disasters but hardware failures and human errors.The goal of Oracle Data Guard is to provide an effective safeguard against data loss. Data Guard provides enterprises with complete data protection, data recovery, and data availability, ensuring round-the-clock business continuity.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Understanding the Causes of Downtime

Planneddowntime

Unplanneddowntime

Systemchanges

Datachanges

Datafailures

Computerfailures

Corruption

Human error

Sitefailure

Storagefailure

Understanding the Causes of DowntimeEvery system faces both unplanned and planned downtime. It is important to consider causes of both unplanned and planned downtime when designing a fault-tolerant, resilient infrastructure.Unplanned downtime consists of the following:

• Computer failures: Downtime occurs when there is a power outage or a system crash.• Data failures: Data failure is the loss, damage, or corruption of critical enterprise data.

Causes of data failure include:- Storage failure: Disk crash or space limitations- Human error: Downtime occurs when someone inadvertently drops a table or the

system administrator makes an error.- Corruption: Caused by a faulty component in the I/O stack- Site failure: Downtime occurs when there is some sort of data corruption or natural

disaster such as a flood, fire, or earthquake. Planned downtime includes routine operations, periodic maintenance, and new deployments. Planned downtime includes the following:

• Data changes: Table redefinition and index rebuild• System changes: Downtime occurs during hardware and operating-system upgrades.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



What Is Oracle Data Guard?

Primarydatabase

Standbydatabase

Database Database copy

Redo transport

Ora

cle

Net

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Types of Standby Databases

There are two types of standby databases:• Physical standby database

– Identical to the primary database on a block-for-block basis

– Synchronized with the primary database through application of redo data received from the primary database

• Logical standby database– Shares the same schema definition– Synchronized with the primary database by transforming

the data in the redo received from the primary database into SQL statements and then executing the SQL statements

Types of Standby DatabasesPhysical Standby DatabaseA physical standby database is physically identical to the primary database, with on-disk database structures that are identical to the primary database on a block-for-block basis. The physical standby database is updated by performing recovery using redo data that is received from the primary database. The physical standby database can be either recovering data or open for read-only reporting.Logical Standby DatabaseA logical standby database contains the same logical information (unless configured to skipcertain objects) as the production database, although the physical organization and structure of the data can be different. The logical standby database is kept synchronized with the primary database by transforming the data in the redo received from the primary database into SQL statements and then executing the SQL statements on the standby database. This is done with the use of LogMiner technology on the redo log information received from the primary database. The tables in a logical standby database can be used simultaneously for recovery and for other tasks such as reporting, summations, and queries.For more information about LogMiner, refer to Oracle Database Utilities.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Oracle Data Guard Broker Framework

CLI management client

Enterprise Manager

Repository

Primarydatabase

DataGuardbroker

Oracle Management

Server

DataGuardbroker

Agent

Standbydatabase

Agent

Oracle Data Guard BrokerThe Oracle Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations. After the broker creates the Data Guard configuration, the broker monitors the activity, health, and availability of all systems in the Data Guard configuration. You can use Oracle Enterprise Manager Grid Control or the Data Guard broker’s own specialized command-line interface (DGMGRL) to take advantage of the broker’s management capabilities.Enterprise Manager provides a Web-based interface that combines with the broker’s centralized management and monitoring capabilities so that you can easily view, monitor, and administer primary and standby databases in a Data Guard configuration.You can also use the Data Guard command-line interface (CLI) to control and monitor a Data Guard configuration. You can perform most of the activities that are required to manage and monitor the databases in the configuration from the CLI prompt (DGMGRL) or in scripts.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Types of Services

There are three types of services provided with Data Guard:• Redo transport services• Log apply services

– Redo Apply– SQL Apply

• Role-management services

Types of ServicesThe following types of services are available with Data Guard:

• Redo transport services: Control the automated transmittal of redo information from the primary database to one or more standby databases or destinations

• Log apply services: Control when and how the redo logs are applied to the standby database

- Redo Apply: Technology used for physical standby databases. Redo data is applied on the standby database by using the standard recovery techniques of an Oracle database.

- SQL Apply: Technology used for logical standby databases. The received redo data is first transformed into SQL statements, and then the generated SQL statements are executed on the logical standby database.

• Role-management services: A database operates in one of two mutually exclusive roles: primary or standby. Role-management services operate in conjunction with the redo transport services and log apply services to change these roles dynamically as a planned transition (called a switchover operation) or as a result of a database failure through a failover operation.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Role Transitions: Switchover and Failover

• Oracle Data Guard supports two role-transition operations:– Switchover

— Planned role reversal— Used for OS or hardware maintenance

– Failover— Unplanned role reversal— Use in emergency— Zero or minimal data loss depending on choice

of data protection mode— Can be initiated automatically when fast-start failover is

enabled• Role-transition operations are not automatically

invoked.

Role Transitions: Switchover and FailoverData Guard enables you to change the role of a database dynamically by issuing SQL statements or by using either of the Data Guard broker’s interfaces. Oracle Data Guard supports two role-transition operations:

• Switchover: The switchover feature provides you with the ability to switch the role of the primary database to one of the available standby databases. The chosen standby database becomes the primary database, and the original primary database then becomes a standby database.

• Failover: You invoke a failover operation when a catastrophic failure occurs on the primary database and there is no possibility of recovering the primary database in a timely manner. During a failover operation, the failed primary database is removed from the Data Guard environment, and a standby database assumes the primary database role. You invoke the failover operation on the standby database that you want to fail over to the primary role. In Oracle Database 10g Release 2, you can enable fast-start failover that allows Data Guard to automatically and quickly fail over to a previously chosen, synchronized standby database. Fast-start failover is discussed in detail in the lesson titled “Enabling Fast-Start Failover.”

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Protection Modes

• Maximum protection• Maximum availability• Maximum performance

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Benefits of ImplementingOracle Data Guard

Oracle Data Guard provides the following benefits:• Continuous service through disasters or crippling data

failures• Complete data protection against corruptions and data

loss• Efficient use of system resources• Elimination of idle standby systems• Flexible configuration of your system to meet business

protection and recovery requirements• Centralized management

Benefits of Implementing Oracle Data GuardOracle Data Guard provides the following benefits:

• Continuous service: With the use of switchover and failover between systems, your business need not halt because of a disaster at one location.

• Complete data protection: Data Guard guarantees no data loss and provides a safeguard against data corruption and user errors. Redo data is validated when applied to the standby database.

• Efficient use of system resources: Standby databases can be used for reporting in addition to providing a safeguard for disaster recovery. You can use a logical standby for real-time reporting and the physical standby database for point-in-time reporting. You can also use the physical standby database for backups of the primary database.

• Elimination of idle standby systems: A standby database does not have to be idle when you implement a logical standby database. This database is open and ready for reporting at all times.

• Flexible configurations: You can use Data Guard to configure the system to your needs. With the use of protection modes and several tunable parameters, you can tailor the configuration to your needs.

• Centralized management: You can use Enterprise Manager Grid Control to manage all configurations in your enterprise.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Role of Data Guard in a High-Availability Architecture

RAC

ASM

Flashback technology

Datafailures

Computerfailures

Corruption

Human error

Sitefailure

Storagefailure

Oracle HARDRMAN

Data Guard

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Role of Data Guard in a High-Availability Architecture

Datachanges

System changes

• Online schema anddata reorganization

• Partitioned tablesand indexes

• Dynamic resourceprovisioning

• Rolling patch updates• Rolling release upgrade

using Data GuardSQL Apply

Planneddowntime

Role of Data Guard in a High-Availability Architecture (continued)There are a number of features in Oracle Database to support planned downtime that encompasses data changes. Tables can be redefined without interruption to users who are viewing or updating the data. Indexes can be added, rebuilt, or defragmented while the tables that they index are being queried or updated. See the Oracle Database Administrator’s Guide for additional information about these features.Oracle Database dynamically accommodates a number of hardware configuration changes.Patches can be applied to a RAC system in a rolling fashion.Oracle Database 10g supports the installation of database software upgrades (and the application of patchsets) in a rolling fashion by using Data Guard SQL Apply.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Oracle Data Guard and Real Application Clusters

Oracle Data Guard and Real Application Clusters are complementary and can be used together.• Real Application Clusters provides high availability.• Oracle Data Guard provides disaster protection and

prevents data loss.

Oracle Data Guard and Real Application ClustersRAC provides the following for high availability:

• Rapid and automatic recovery from node failures or an instance crash• Increased scalability

Oracle Data Guard provides disaster protection and prevents data loss by:• Maintaining transactionally consistent copies of the primary database• Protecting against data corruption• Protecting against user errors• Not requiring expensive and complex mirroring of hardware or software

RAC is covered in greater detail in the lesson titled “Using Data Guard in a Real Application Clusters Configuration.”

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Maximum Availability Architecture

RAC productiondatabase

RAC physicalstandby database

Oracle Application

Server

Oracle Application

Server

WAN traffic manager

Clients

Data Guard RAC logical

standby database

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to:• Describe the basic components of Oracle Data Guard• Describe the differences between physical and logical

standby databases• Determine when Oracle Data Guard is an appropriate

solution in your Oracle Database configuration• Explain the use of Data Guard in high-availability

architectures

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Practice 1: Overview

This practice covers the following topics:• Reviewing the factors that affect planned and

unplanned downtime• Reviewing the differences between physical and logical

standby databases• Reviewing the components of Oracle Data Guard

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Understanding the OracleData Guard Architecture

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to do the following:• Describe the Data Guard architecture• Explain the operational requirements of Data Guard• Describe how Data Guard processes, transports, and

applies redo logs• Describe standby database modes

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Operational Requirements: Hardware and Operating System

• The hardware can be different for the primary and standby databases.

• The operating system and platform architecture for the primary and standby databases must be the same.

• The operating system releases for the primary and standby databases can be different.

• If all databases are on the same system, verify that the OS allows you to mount more than one database with the same name.

Hardware and Operating System RequirementsThese are the operational requirements for Data Guard with respect to the hardware and the operating system:

• The hardware for the primary and standby database systems can be different. For example, the number of CPUs, the memory size, and the storage configuration can differ.

• The operating system and platform architecture for the primary and standby databases must be the same.

• The operating system on both databases must be the same, but the operating system release does not need to be the same. Note: Standby databases can use a different directory structure from the primary database.

• If both the primary and the standby databases are on the same server, you must ensure that the operating system allows you to mount two databases with the same name on the same system simultaneously. There are certain parameters that must be specified to support this configuration, as discussed in the lesson titled “Creating a Physical Standby Database by Using SQL.”

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Operational Requirements: Oracle Database Software

• Same release of Oracle Database Enterprise Edition must be installed for all databases.

• SYSDBA privileges are required for the accounts used to manage the database instances.

• Each database must have its own control file.• Primary database must operate in ARCHIVELOG mode.• Enable FORCE LOGGING on the primary database before

taking data file backups for standby creation.• If any databases use ASM and/or OMF, all should use

the same combination.

Oracle Database Software RequirementsThese are the operational requirements for Data Guard with respect to Oracle Database software:

• You must install the same release of Oracle Database Enterprise Edition for the primary database and all standby databases in your Data Guard configuration.

• You must have SYSDBA system privileges for the user accounts that you use to manage the primary and standby database instances. Furthermore, the SYS user must have the same password on all databases in the configuration.

• The primary database and each standby database must have their own control files.• The primary database must be configured in ARCHIVELOG mode.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Oracle Database Software Requirements (continued)• Some data definition language (DDL) statements permit the NOLOGGING clause, which causes

some database operations not to generate redo records in the database redo log. The NOLOGGING setting can speed up operations that can be easily recovered outside of the database recovery mechanisms, but it can negatively affect media recovery and standby databases. You can enable FORCE LOGGING to force the writing of redo records even when NOLOGGING has been specified in DDL statements. To protect against unlogged direct writes in the primary database that cannot be propagated to the standby database, enable FORCELOGGING on the primary database before taking data file backups for standby creation. You should maintain FORCE LOGGING mode as long as the standby database is active.

• If you use Oracle Automatic Storage Management (ASM) and Oracle Managed Files (OMF) in a Data Guard configuration, you should use ASM and OMF symmetrically on the primary and standby database. If any database in your Data Guard configuration uses ASM, OMF, or both, then every database in the configuration should use ASM, OMF, or both, respectively.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Oracle Data Guard: Architecture

LGWR

Primary database

transactions

Onlineredologs

ARC0

FAL

RFS

MRP or LSP

Archived redo logs

ARC0

Standbydatabase

Reports

(MRP only)

Standbyredo logs

Archived redo logs

BackupOra

cle

net

LNSn

(Real-time apply)

Oracle Data Guard: ArchitectureOracle 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Primary Database Flow

LGWR

Primary database

transactions

Onlineredologs

ARC0

FAL

RFS

MRP or LSP

Archived redo logs

ARC0

Standbydatabase

Reports

(MRP only)

Standbyredo logs

Archived redo logs

BackupOra

cle

net

LNSn

(Real-time apply)

Primary Database FlowOn the primary database, Data Guard redo transport services use the following processes:

• Log writer (LGWR) process: LGWR collects transaction redo information and updates the online redo logs. In synchronous mode, it ships redo information directly to the remote file server (RFS) process on the standby database and waits for a confirmation before proceeding. In asynchronous mode, it ships the redo information directly but does not wait before proceeding. In asynchronous mode, LGWR submits the network I/O request to the network server (LNSn) process for that destination.

• Archiver (ARCn) process: ARCn, or a SQL session performing an archival operation, creates a copy of the online redo logs locally for use in a primary database recovery. The ARCn process may also ship the redo stream to the RFS process while simultaneously archiving the online log. ARCn is also responsible for proactively detecting and resolving gaps on all standby databases.

• Fetch archive log (FAL) (physical standby databases only): FAL provides a client/server mechanism for resolving gaps detected in the range of archived redo logs that are generated at the primary database and received at the standby database. This process is started only when needed and shuts down as soon as it is finished. It is very likely you will not see this process running.

Note: You can configure a primary database to ship redo information to a single standby database by using either LGWR or ARCn, but not both.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Standby Database Flow

LGWR

Primary database

transactions

Onlineredologs

ARC0

FAL

RFS

MRP or LSP

Archived redo logs

ARC0

Standbydatabase

Ora

cle

net

Reports

(MRP only)

Standbyredo logs

Archived redo logs

Backup

LNSn

(Real-time apply)

Standby Database FlowOn the standby database, Data Guard log apply services use the following processes:

• Remote file server (RFS) process: RFS receives redo information from the primary database. RFS can write the redo into standby redo logs or directly to archived redo logs. 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 later in the lesson.

• Archiver (ARCn) process: The ARCn process archives the standby redo logs. • Managed recovery process (MRP): For physical standby databases only, MRP applies

archived redo log information to the physical standby database. If you start the managed recovery with the 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 Data Guard broker to manage your standby databases, the broker always starts the MRP background process for a physical standby database.

• Logical standby process (LSP): For logical standby databases only, LSP controls the applying of archived redo log information to the logical standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Standby Redo Logs

Redo from primary database

RFS ARC0

Standbyredo logs

Archivedredo logs

MRP/LSP

Standby database

Standby Redo LogsA standby redo log is used only when the database is in the standby role to store redo data received from the primary database. Standby redo logs form a separate pool of log file groups.Configuring standby redo log files is highly recommended on all standby databases in a Data Guard configuration, including the primary database to aid in role reversal.A standby redo log is required to implement:

• The maximum protection and maximum availability levels of data protection • Real-time apply • Cascaded redo log destinations

Standby redo logs are recommended for maximum performance data protection mode. Unless you are using the real-time apply feature, standby redo logs must be archived before the data can be applied to the standby database. The standby archival operation occurs automatically.Note: The real-time apply feature is discussed in more detail later in this lesson.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Physical Standby Database: Redo Apply Architecture

Physical standby database

Primary database

Productiondatabase

Physical standbydatabase

Redoapply

Redo stream

Redotransport

Backup

Data Guard Redo Apply: ArchitectureThe Data Guard physical standby Redo Apply architecture consists of:

• A production (primary) database, which is linked to one or more standby databases (up to nine) that are identical copies of the production database

- The limit of nine standby databases is imposed by the LOG_ARCHIVE_DEST_n parameter. In Oracle Database 10g, the maximum number of destinations is 10. One is used as the local archive destination, leaving the other nine for uses such as the standby database. Note: You can use the Cascaded Redo Log Destinations feature to incorporate more than nine standby databases in your configuration. Refer to the lesson titled “Other Considerations for Oracle Data Guard” for additional information about this feature.

- The primary database is open and active. The standby databases are either in recovery mode or open in read-only mode, but not both.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Data Guard Redo Apply: Architecture (continued)• The standby database, which is updated by redo that is automatically shipped from the primary

database. The redo can be shipped because it is generated or archived on the primary database.- Redo is applied to each standby database by using standard Oracle recovery techniques.- During planned downtime, you can perform a switchover to a standby database.- When a failure occurs, you may perform a failover to one of the standby databases. - The physical standby database can also be used to back up the primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Logical Standby Database:SQL Apply Architecture

Primarydatabase

Redo transport

Transform redo information into

SQL

SQL Apply

Reports

Productiondatabase

Logical standbydatabase

Logical standby database

Data Guard SQL Apply: ArchitectureIn 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Redo records

LCRLCR

:

Shared pool

Transaction groups

Transactions sorted in

dependency order

Log Mining

Apply processing

Logical change records not grouped into transactions

Transactions to be applied

Reader Preparer Builder

AnalyzerCoordinatorApplier

Data files

Redo data from primary database

SQL Apply Process: Architecture

SQL Apply Process: ArchitectureSQL 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 (the

transactions are scheduled appropriately so that the dependencies are resolved) - Commits the transactions

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Real-Time Apply

RFS

Standbyredo log

files

MRP or LSP

ARC0

Primary database

Standby database

Archivedredo log

files

Real-Time ApplyWhen 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 quicker switchover and failover operations, instantly up-to-date results after you change a physical standby database to read-only, up-to-date reporting from a logical standby database, and the ability to leverage larger logs files.Having larger log files with real-time apply is desirable because the apply service stays with a log longer and the overhead of switching has less impact on the real-time apply processing.The RECOVERY_MODE column of the V$ARCHIVE_DEST_STATUS view contains the value MANAGED REAL TIME APPLY when log apply services are running in real-time apply mode.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Real-Time Apply (continued)If you define a delay on a destination (with the DELAY attribute) and use real-time apply, the delay is ignored.For physical standby databases, the managed recovery process (MRP) applies the redo from the standby redo log files after the remote file server (RFS) process finishes writing. To start real-time apply for a physical standby database, issue the following command:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

For logical standby databases, the logical standby process (LSP) applies the redo from the standby redo log files after the RFS process finishes writing. To start real-time apply for a logical standby database, issue the following command:

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Note: Standby redo log files are required for real-time apply. It is highly recommended that you have one more standby redo log group than the number of online log groups on the primary database.Real-time apply is supported by the broker.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting the DB_UNIQUE_NAME Parameter

DB_UNIQUE_NAME = SF1_DB

San Francisco

SF1_DB

Setting the DB_UNIQUE_NAME ParameterData Guard identifies all the databases in its configuration by using the DB_UNIQUE_NAMEinitialization parameter. Choose a unique name for each database and assign it with this parameter. The DB_UNIQUE_NAME value must remain constant for a given database. Therefore, you should choose names that are easy for you to remember and identify, and you should not change the names after you have assigned them. Each DB_UNIQUE_NAME value can be up to 30 characters long and must be the same for all instances in a RAC database. The default is the database name. If you use Enterprise Manager to create a standby database, it sets this to a unique value for the new standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Specifying Role-Based Destinations

Primarydatabase

Standbydatabase

LOG_ARCHIVE_DEST_2= location= "/u01/app/oracle/oradata/orcldg2/arc", valid_for=(STANDBY_LOGFILE,STANDBY_ROLE)DB_UNIQUE_NAME = HRDB2

Not used

Specifying Role-Based DestinationsThe VALID_FOR attribute of the LOG_ARCHIVE_DEST_n initialization parameter allows you to identify exactly when the archive destination is to be used, as well as for which type of log file it is used. The attribute uses a keyword pair to identify the source of the archival as well as the database role.In the example in the slide, there is a destination on the standby database and the primary database defined with the VALID_FOR setting shown. This destination is 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: archival_source and database_role.The archival_source keywords are the following:• ONLINE_LOGFILE: This destination is used only when archiving online redo log files.• STANDBY_LOGFILE: This destination is used only when archiving standby redo log files or

receiving archive logs from another database. • ALL_LOGFILES: This destination is used when archiving either online or standby redo log

files.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Specifying Role-Based Destinations (continued)The database_role keywords are the following:• PRIMARY_ROLE: This destination is used only when the database is in the primary database

role.• STANDBY_ROLE: This destination is used only when the database is in the standby (logical or

physical) role.• ALL_ROLES: This destination is used when the database is in either the primary or standby

(logical or physical) role.Note: Because the keywords are unique, the archival_source and database_role values can be specified in any order. For example, VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILE) is functionally equivalent to VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE).

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Combinations for VALID_FOR

ValidValidValidALL_LOGFILES, ALL_ROLES

ValidValidIgnoredALL_LOGFILES, STANDBY_ROLE

IgnoredIgnoredValidALL_LOGFILES, PRIMARY_ROLE

ValidValidIgnoredSTANDBY_LOGFILE, ALL_ROLES

ValidValidIgnoredSTANDBY_LOGFILE,STANDBY_ROLE

Ignored

Ignored

Ignored

Physical

ValidValidONLINE_LOGFILE, ALL_ROLES

ValidIgnoredONLINE_LOGFILE, STANDBY_ROLE

IgnoredValidONLINE_LOGFILE, PRIMARY_ROLE

LogicalPrimaryCombination

Combinations for VALID_FORIn the table, the word Valid means that the archive log destination is used in a database that is in the role defined by the column heading. The Ignored value means the archive log destination is not appropriate and a destination of this type is ignored. An ignored destination does not generate an error.ALL_LOGFILES, ALL_ROLES is not a recommended setting for a logical standby for any destination. Because a logical standby is an open database that is creating its own redo, there is a real possibility of having the log files overwrite each other. This gives you a system that is unrecoverable and/or unable to keep synchronized with the primary database.There is only one invalid combination: STANDBY_LOGFILE, PRIMARY_ROLE. If this is specified, it causes an error for all database roles. If this is set, you receive the following error at startup:

ORA-16026: The parameter LOG_ARCHIVE_DEST_n contains an invalid attribute value

Note: Both the single and plural forms of the keywords are valid. For example, you can specify either PRIMARY_ROLE or PRIMARY_ROLES, and ONLINE_LOGFILE or ONLINE_LOGFILES.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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







11 ALL_LOGFILES ALL_ROLES YES

11 rows selected.

Identifying Destination SettingsThe VALID_NOW column in V$ARCHIVE_DEST indicates whether or not the archive log destination is used. The column values are the following:

• YES: This value indicates that the archive log destination is appropriately defined for the current database role.

• WRONG VALID_TYPE: This value indicates that the archive log destination is appropriately defined for the current database role but cannot be used. For example, LOG_ARCHIVE_DEST_2 is set to (STANDBY_LOGFILES,STANDBY_ROLE), but WRONG VALID_TYPE is returned because this standby destination does not have a standby redo log implemented.

• WRONG VALID_ROLE: This value indicates that the archive log destination is not appropriately defined for the current database role. For example, LOG_ARCHIVE_DEST_3 is set to (ONLINE_LOGFILES,STANDBY_ROLE), but WRONG VALID_ROLE is returned because this destination is currently running in the primary database role.

• UNKNOWN: This value indicates that the archive log destination is not defined.The VALID_TYPE and VALID_ROLE columns are the respective values from the VALID_FORattribute that is specified for each archive log destination.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Standby Redo Log Configuration

Redo shipment

RFS

Standbyredo logs

Onlineredo logs

Primarydatabase

Standbydatabase

Standby Redo Log ConfigurationYou must create at least the same number of standby redo log files as are contained on the primary database. It is highly recommended that you have one more standby redo log group than you have online redo log groups as the primary database. In addition, the files must be the same size or larger than the primary database’s online redo logs. If your online redo log files are of different sizes, the RFS process automatically uses the same size standby redo log as the online redo log file.The RFS process writes to an archive redo log file if any of the following conditions are met:

• There are no standby redo logs.• It cannot find the same size standby redo log as the incoming online redo log file.• All of the standby redo logs of the correct size have not yet been archived.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using SQL to Add Standby Redo Logs

• Use the ALTER DATABASE statement to create the standby redo log files:

• Add members to a group with the following statement:

• View information about the groups as follows:

SQL> ALTER DATABASE ADD STANDBY LOGFILE MEMBER 2 '/oracle/oradata/orcl/log2b.rdo' TO GROUP 2;

SQL> ALTER DATABASE ADD STANDBY LOGFILE2 ('/oracle/oradata/orcl/log1c.rdo',3 '/oracle/oradata/orcl/log2c.rdo') SIZE 500K;

SQL> SELECT * FROM v$standby_log;SQL> SELECT * FROM v$logfile

2 WHERE type = 'STANDBY';

Using SQL to Add Standby Redo LogsYou can create standby redo logs by using the ADD STANDBY LOGFILE clause of the ALTERDATABASE statement. Although standby redo logs are used only when the database is operating in the standby role, you should create standby redo logs on the primary database so that switching roles does not require additional DBA intervention.To verify that standby redo logs have been created, query V$STANDBY_LOG or V$LOGFILE with SELECT * FROM v$logfile WHERE type = 'STANDBY'.The standby redo log status is shown as ACTIVE or UNASSIGNED.The following is an example of output from V$STANDBY_LOG:

SQL> SELECT group#,status,first_change# 2 FROM v$standby_log;

GROUP# STATUS FIRST_CHANGE#------ ---------- -------------

3 ACTIVE 1445454 UNASSIGNED 05 UNASSIGNED 0

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Enterprise Managerto Add Standby Redo Logs

Using Enterprise Manager to Add Standby Redo LogsWhen you create a standby configuration with Enterprise Manager, it recommends a configuration of standby redo logs. This recommendation includes creating the standby redo logs on the primary database as well as on any standby databases in the configuration.Configuring standby redo logs is covered in more detail in the lesson titled “Creating a Configuration and Physical Standby Database by Using Enterprise Manager.”

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Standby Database Modes

You can maintain the standby data in one of the following modes:• For physical standby databases

– Redo Apply– Open read-only mode

• For logical standby databases– Open read/write mode

Standby Database ModesYou can use log apply services to maintain your physical standby database in one of the following modes:

• Redo Apply: In this mode, redo transport services archive the logs to the standby database, and log apply services automatically apply these logs. The database is in the MOUNT state; no reads of the data are possible.

• Open read-only mode: If you want to use the standby database for reporting purposes, then open it in read-only mode in a Data Guard environment. Log apply services cannot apply archived redo logs to the standby database when it is in this mode, but the primary database continues to ship redo to the standby database.

You can easily change between managed recovery mode and read-only mode. In most implementations of a Data Guard environment, you may want to make this transition at various times so that you can do one of the following:

• Update a physical standby database that is used primarily for reporting• Ensure that data is correctly applied to a physical standby database that is used primarily for

disaster protection

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Standby Database Modes (continued)• Open read/write mode: In this mode, log apply services continue to manage the application of

log information from archived redo logs. In addition, the database is open for reporting.The logs are being applied to the logical standby database while users are allowed to perform queries on the tables that are being updated by the log apply service. Users are not allowed to perform DML on the tables in the schemas that the log apply service is maintaining. However, users can modify database objects in other schemas that are not being maintained by the log apply service.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to describe the following:• Data Guard architecture processes• Operational requirements of a Data Guard environment• How Data Guard processes, transports, and applies

redo logs• Modes of standby databases and when to use each

mode

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Practice 2-1: Architecture Review

This practice covers the following topics:• Reviewing the Oracle Data Guard architecture• Reviewing the processes that Data Guard uses to

transport and apply redo logs• Reviewing the modes that are used to recover a

primary database

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Practice 2-2: Installing the Oracle Management Agent

This practice covers the following topics:• Installing the Oracle Management Agent• Configuring monitoring credentials for your database

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Practice 2-3: Configuring Your Primary Database

This practice covers the following topics:• Reviewing your primary database configuration • Configuring your primary database in preparation for

creating a Data Guard configuration

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Using Data Guard Brokerand Enterprise Manager

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to do the following:• Describe the Data Guard broker architecture• Describe the Data Guard broker components• Explain the benefits of the Data Guard broker• Explain Data Guard broker configurations• Use Enterprise Manager to manage your Data Guard

configuration• Invoke DGMGRL to manage your Data Guard

configuration

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Features of Data Guard Broker

• The Data Guard broker is a distributed management framework.

• The broker automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations.

• With the broker, you can perform all management operations locally or remotely through easy-to-use interfaces: – Oracle Enterprise Manager 10g Grid Control– A command-line interface: DGMGRL

Features of Data Guard BrokerThe Oracle Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations. The following are some of the operations that the broker automates and simplifies:

• Automated creation of Data Guard configurations incorporating a primary database, a new or existing (physical or logical) standby database, redo transport services, and log apply servicesNote: Any of the databases in the configuration can be a RAC database.

• Adding up to eight new or existing (physical or logical, RAC or non-RAC) standby databases to each existing Data Guard configuration, for a total of one primary database, and from one to nine standby databases in the same configuration

• Managing an entire Data Guard configuration (including all databases, 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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Broker: Components

• Client-side:– Oracle Enterprise Manager 10g Grid Control– DGMGRL (command-line interface)

• Server-side: Data Guard monitor– DMON process– Configuration files

Data Guard Broker: ComponentsThe Oracle Data Guard broker consists of components that reside on the client and the server in the configuration.On the client, you can use the following Data Guard components to define and manage a configuration:

• Oracle Enterprise Manager• DGMGRL, which is the Data Guard command-line interface (CLI)

On the server, Data Guard monitor is a broker component that is integrated with the Oracle database. Data Guard monitor comprises the Data Guard monitor process (DMON) and broker configuration files, with which you can control the databases of that configuration, modify their behavior at run time, monitor the overall health of the configuration, and provide notification of other operational characteristics.The configuration file contains profiles that describe the states and properties of the databases in the configuration. Associated with each database are various properties that the DMONprocess 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Broker: Configurations

The most common configuration is a primary database at one location and a standby database at another location.

Chicago

Primary site

Boston

Standby site

Oracle Net

Data Guard Broker: ConfigurationsA Data Guard configuration consists of one primary database and up to nine standby databases. The databases in a Data Guard configuration are typically dispersed geographically and are connected by Oracle Net.A Data Guard broker configuration is a logical grouping of the primary and standby databases in a Data Guard configuration. The broker’s DMON process configures and maintains the broker configuration components as a unified group of resource objects that you can manage and monitor as a single unit.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Broker: Management Model

Data Guard Broker Configuration

Primary database

Broker-controlled databases

Standby databaseStandby database




Standby database

Instances Instances

Data Guard Broker: Management ModelThe Data Guard broker performs operations on logical objects:

• Configuration of databases• A single database

A broker configuration consists of:• A configuration object: A named collection of database profiles. A database profile is a

description of a database object, including its current state, current status, and properties. • Database objects: Objects corresponding to primary or standby databases • Instance objects: A database object may 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 nine physical, logical, RAC or non-RAC standby databases.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Primary site

Standby site 9Standby site 2

Data Guard Broker: Architecture

Graphical user interfaceor

command-line interface

DMON

Archivedredo logs

Onlineredo logs

Standby site 1

OracleNet

Standbyredo logs Archived

redo logs

Logapply

services

Data Guard Configuration

Logtransportservices

Primary database

DMON

Configurationfiles

Configurationfiles Standby

database

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Life Cycle of a Broker Configuration

Createconfiguration

Enableconfiguration

Make state orrole changes

Update databaseproperties

Monitor and tuneconfiguration

Life Cycle of a Broker ConfigurationYou can use the Add Standby Database Wizard in Enterprise Manager to add an existing standby database to the configuration or create a new standby database and add it to the configuration. The standby database can be either a physical or a logical database.Note: If you are creating a new database, it must be a non-RAC database.If you are using the CLI, the primary database and standby database must already exist. You must construct the standby database from backups of the primary database control files and data files, and then prepare it for recovery.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Broker: Requirements

• Enterprise Edition of Oracle Database 10g• Single-instance or multi-instance environment• COMPATIBLE must be set to 9.2.0.1.0 or higher for

primary and standby databases.• Oracle Net network files must be configured for

databases that you add to the configuration.• LOCAL_LISTENER on each instance must resolve to an

address that is reachable by all members.• GLOBAL_DBNAME attribute must be set to a

concatenation of: db_unique_name_DGMGRL.db_domain

Data Guard Broker: RequirementsTo use the Data Guard broker, you must comply with the following requirements:

• You must use the Enterprise Edition of Oracle Database 10g.• You can use a single-instance or multi-instance environment.• You must set the COMPATIBLE initialization parameter to 9.2.0.1.0 or higher for the

primary and standby databases. To take advantage of new Oracle Database 10g features, set the COMPATIBLE parameter to 10.2.0.0.

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

• The value of the LOCAL_LISTENER initialization parameter on each instance that is part of your Data Guard broker configuration must resolve to a listener address that is reachable by all members of the configuration.

• To enable the Data Guard broker CLI to restart instances during the course of broker operations, a service with a specific name must be statically registered with the local listener of each instance. The value of the GLOBAL_DBNAME attribute must be set to a concatenation of db_unique_name_DGMGRL.db_domain.

Note: Oracle Enterprise Manager 10g can manage a 9.2 Data Guard configuration.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Broker: Requirements

• DG_BROKER_START = TRUE

• The primary database must be in ARCHIVELOG mode.• All databases must be in MOUNT or OPEN mode.• Configure DG_BROKER_CONFIG_FILEn for any RAC

databases.• START_OPTIONS for any RAC databases must be set to

MOUNT in the Oracle Cluster Repository (OCR).

Data Guard Broker: Requirements (continued)• You must set the DG_BROKER_START initialization parameter to TRUE. This enables

the DMON process. Note: 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, if available, or on raw devices.

• If any database in your configuration is a RAC database, the START_OPTIONS for that database must be set to MOUNT in the Oracle Cluster Repository (OCR) using SRVCTL, as follows:SRVCTL ADD DATABASE -d <db_unique_name> -o <$ORACLE_HOME> -s MOUNT

orSRVCTL MODIFY DATABASE -d <db_unique_name> -o <$ORACLE_HOME> -s MOUNT

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Broker and the SPFILE

• You must use a server parameter file (SPFILE) for initialization parameters.

• Using the SPFILE enables the Data Guard broker to keep its configuration file and the database SPFILE consistent.

• If you use the broker, use Enterprise Manager or DGMGRL to update database parameter values.

Data Guard Broker and the SPFILETo ensure that the broker can update the values of parameters both in the database instance and in the configuration file, you must use the persistent server initialization parameter file (SPFILE) to control static and dynamic initialization parameters. Use of the SPFILE gives the broker a mechanism that enables it to reconcile property values that you have selected when using the broker with any related initialization parameter values that are recorded in the SPFILE. Also, the SPFILE permits persistent Data Guard settings, so that Data Guard continues to work even after the broker is disabled.When you set definitions or values for database properties in the broker configuration, the broker records the change in the configuration file and also propagates the changes to the related initialization parameters in the 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Monitor: DMON Process

• Server-side background process• Part of each database instance in the configuration• Created when you start the broker• Performs requested functions and monitors the

resource• Communicates with other DMON processes in the

configuration• Updates the configuration file

Data Guard Monitor: DMON ProcessThe Data Guard monitor comprises two components: the DMON process and the configuration file.The Data Guard Monitor process (DMON) is an Oracle background process that is part of each database instance managed by the broker. When you start the Data Guard broker, a portion of the SGA is allocated and a DMON process is created. The amount of memory allocated is typically less 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Monitor: Configuration File

• Automatically created and named using a default path name and file name when the broker is started

• Override default path name and file name by setting DG_BROKER_CONFIG_FILEn .

• Two files at each managed site• Managed automatically by the DMON process• Default names are dr1<db_unique_name>.dat and

dr2<db_unique_name>.dat.

• Default locations are operating system specific:– Default location for UNIX and Linux: ORACLE_HOME/dbs– Default location for Windows: ORACLE_HOME\database

Data Guard Monitor: Configuration FileThe 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_FILEn initialization parameters. You can also change the configuration file names dynamically by issuing the ALTER SYSTEM SQL statement.The configuration files contain entries that describe the state and properties of the databases in the configuration. For example, the files record the databases that are part of the configuration, the roles and properties of each of the databases, and the state of each of the databases in the configuration. Two files are maintained so that there is always a record of the last known valid state of the configuration. The broker uses the data in the configuration file to configure and start the databases, control each database’s behavior, and provide information to the CLI and Enterprise Manager.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Benefits of Using the Data Guard Broker

• Enhances the high-availability, data protection, and disaster protection capabilities inherent in Oracle Data Guard by automating both configuration and monitoring tasks

• Streamlines the process for any one of the standby databases to replace the primary database and take over production processing

• Helps you logically define and create a Data Guard configuration consisting of a primary database and a standby database

• Enables easy configuration of additional standby databases

Benefits of Using the Data Guard BrokerBy 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.Using the broker, you can logically define and create a Data Guard configuration consisting of a primary database and a (physical or logical, RAC or non-RAC) standby database. The broker enables easy configuration of additional standby databases. After you create a Data Guard configuration consisting of a primary and a standby database, you can add up to eight standby databases (new or existing, physical or logical) to each Data Guard configuration.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Benefits of Using the Data Guard Broker

• Provides simplified, centralized, and extended management

• Automates switchover and failover to a specified standby database in the broker configuration

• Automatically communicates between the databases in a Data Guard configuration using Oracle Net Services

• Provides built-in validation that monitors the health of all the databases in the configuration

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Broker Interfaces

• Oracle Enterprise Manager 10g Grid Control:– Contains wizards to simplify creating and managing

standby databases• Command-line interface (CLI):

– Started by entering DGMGRL at the command prompt where the Oracle server is installed

– Enables you to control and monitor a Data Guard configuration from the CLI prompt or in scripts

Data Guard Broker InterfacesOracle Enterprise Manager automates and simplifies the management of a Data Guard configuration.Oracle Enterprise Manager 10g Grid Control includes the following Data Guard features:

• Wizard-driven creation of standby databases• Wizard-driven creation of a broker configuration based on an existing primary and

standby database• Complete monitoring and proactive event reporting through e-mail or pagers• Simplified control of the databases through their potential states. For example, with

Enterprise Manager you can take a database offline, put it online, start or stop the redo transport services, start or stop the log apply services, place a standby database in read-only mode, and so on.

• “Pushbutton” switchover and failover: Grid Control enables you to execute a switchover or failover between a primary and a standby database by simply clicking a button.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Data Guard Broker Interfaces (continued)The DGMGRL command-line interface (CLI) includes:

• Configuration and setup tasks• Management and control of the configuration• Commands to check the status and health of the configuration• Commands to execute role changes

For additional information about using these interfaces, see Oracle Data Guard Broker.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Oracle Enterprise Manager 10gGrid Control

Click “Setup and Manage” to access the Data Guard pages.

Using Oracle Enterprise Manager 10g Grid ControlAccess the Data Guard features in Grid Control by performing the following steps:

1. Click the Targets tab to go to the Targets page.2. Click Databases to go to the Databases page.3. On the Databases page, you can see a list of all discovered databases, including the

primary database. Click the primary database to go to the primary database home page.4. Click Maintenance.5. Click “Setup and Manage’’ in the Data Guard section.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Guard Overview Page

Data Guard Overview PageOn the Data Guard Overview page, you can:

• View the protection mode and access the page to edit the protection mode• View a summary showing the amount of data that the standby has not received• View information about the primary database• View or access pages to change information for the standby databases:

- Add a standby database to the broker configuration.- Change the state or properties.- Discontinue Data Guard broker control.- Switch the role from standby to primary.- Transition the standby database to the role of primary database.

• Access pages to view performance information for the configuration and status of online redo log files for each standby database

• Perform a verification process on the Data Guard configurationYou can click Help to access information about using each page.Note: The Data Guard Overview page is displayed when you click “Setup and Manage” in the Data Guard section of the database Maintenance page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Enterprise Manager Metrics and Alerts

• Metrics: Units of measurement used to assess the health of your system

• Thresholds: Boundary values against which monitored metric values are compared

• Alert: Generated when a threshold is reached

Enterprise Manager Metrics and AlertsMetrics are units of measurement that are used to assess the health of your system. Each target comes with a predefined set of metrics. Metrics have thresholds associated with them.Thresholds are boundary values against which monitored metric values are compared. Some of the thresholds are predefined by Oracle; others are not.When a threshold is reached, an alert is generated. An alert is an indicator signifying that a particular condition has been encountered. An alert is triggered when one of the following conditions is true:

• A threshold is reached• An alert has been cleared• The availability of a monitored service changes• A specific condition occurs. For example, an alert is triggered whenever an error message

is written to a database alert log file.Alerts are detected through a polling-based mechanism by checking for the monitored condition from a separate process at regular, predefined intervals. You can associate an alert with a notification, with the automatic execution of a job, and so on.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Data Guard Metrics

Enterprise Manager includes the following Data Guard metrics:• Data Guard Fast-Start Failover• Data Guard Fast-Start Failover

Observer• Data Guard Performance• Data Guard Status

Using Data Guard MetricsYou can use Enterprise Manager to monitor the status and log file activity. In addition, Enterprise Manager automatically monitors the status and archived redo log file activity on the primary and standby databases and provides the following metrics:

• Data Guard Fast-Start Failover: When Fast-Start Failover is enabled, this metric generates a critical alert on the new primary database (old standby database) if a fast-start failover occurs.

• Data Guard Fast-Start Failover Observer: This metric shows you the current status of the Fast-Start Failover observer. A down status triggers an alert.

• Data Guard Performance: This metric provides alerts for performance 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 notify you with an e-mail message if any of the metrics are triggered. Refer to the Oracle Data Guard Broker 10g Release 2 (10.2) reference manual for detailed information.Note: These metrics are seen on the primary database only.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Managing Data Guard Metrics

1. Configure notification methods.2. View the All Metrics page.3. Set or change Data Guard metric thresholds.4. View triggered metrics.

Managing Data Guard MetricsYou can specify that an e-mail notification be sent to you when a Data Guard metric is triggered. Use the following procedure to configure the notification:

1. Configure notification methods in Enterprise Manager.a. Click Setup at the top of the Database Home page.b. Click Notification Methods on the Setup page.c. Enter the appropriate information in the Mail Server section and click Apply. You

can click Test Mail Servers to verify your configuration.2. View the All Metrics page by clicking All Metrics in the Related Links section on the

Database Home page. Then, view all 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. You can set and change the Data Guard Status metric on the Metrics Thresholds tab of the Metric and Policy Settings page.

4. View triggered metrics: If a metric condition is triggered or a threshold value is exceeded, an alert is issued. Click Data Guard on the All Metrics page to view triggered metrics. You can click the metric and then click a particular database to see details.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Benefits of Using Enterprise Manager

• Enables you to manage your configuration using a familiar interface and event-management system

• Automates and simplifies the complex operations of creating and managing standby databases through the use of wizards

• Performs all Oracle Net Services configuration changes that are necessary to support 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 ManagerManaging your Data Guard configuration with Oracle Enterprise Manager 10g Grid Control provides the following benefits:

• Enables you to manage your configuration using the familiar Enterprise Manager interface and event-management system

• Provides a wizard that automates the complex tasks involved in creating a broker configuration

• Provides the Add Standby Database Wizard to guide you through the process of adding more databases

• Performs all Oracle Net Services configuration changes that are necessary to support 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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using the Command-Line Interfaceof the Data Guard Broker

DGMGRL> connect sys/oracleConnected.DGMGRL> show configuration verbose

ConfigurationName: EDRSR8P1_ORCL.oracle.comEnabled: YESProtection Mode: MaxPerformanceFast-Start Failover: DISABLEDDatabases:EDRSR8P1_ORCL - Primary databaseEDRSR8P1_SITE1 - Physical standby databaseEDRSR8P1_SITE2 - Logical standby database

Current status for "EDRSR8P1_ORCL.oracle.com":SUCCESS

DGMGRL CommandsThe following commands are available in DGMGRL (the Data Guard CLI). Many of these commands have additional arguments that are not described here. This is simply an overview listing.• ADD: Adds a standby database to the broker configuration• CONNECT: Connects a given username to the specified instance• CREATE: Enables you to create broker configurations• DISABLE: Enables you to disable broker control of a configuration or database so that

the object is no longer managed by the broker• EDIT: Used to edit a configuration, database, or instance• ENABLE: Enables you to enable broker control of a configuration or database• EXIT/QUIT: Exits the Data Guard CLI (DGMGRL)• FAILOVER: Performs a database failover operation in which one of the standby

databases changes to the role of primary database. This is an unplanned transition that may result in the loss of application data.

• HELP: Displays online help for the commands in DGMGRL• 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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


DGMGRL Commands (continued)• SHOW: Displays either a brief or a detailed summary of information about the broker

configuration, database, or instance. Also, it can display the dependency tree and default online states for the broker configuration, as well as the configuration log or the Oracle database alert log.

• SHUTDOWN: Shuts down a currently running Oracle database instance• 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

Note: The ALTER command has been deprecated in Oracle Database 10g. The new EDITcommand provides comparable functionality.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to:• Describe the Data Guard broker management model• Describe the Data Guard broker architecture• Describe Data Guard broker components• Access Enterprise Manager• Invoke DGMGRL (the Data Guard CLI)

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Creating a Configuration and Physical Standby Database by Using Enterprise

Manager

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to do the following:• Enable FORCE LOGGING• Use Enterprise Manager to create a broker

configuration• Use Enterprise Manager to monitor the broker

configuration

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Enabling FORCE LOGGING Mode

• Forced logging is recommended to ensure data consistency.

• FORCE LOGGING forces redo to be generated even when NOLOGGING operations are executed.

• Temporary tablespaces and temporary segments are not logged.

• FORCE LOGGING is recommended for both physical and logical standby databases.

• Issue the following command on the primary database:SQL> ALTER DATABASE FORCE LOGGING;

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

• NOFORCE LOGGING: Places the database in NOFORCE LOGGING mode. This is the default.

The FORCE_LOGGING column in V$DATABASE contains a value of YES if the database is in FORCE LOGGING mode.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Enterprise Manager to Create a Broker Configuration

• Use the Add Standby Database Wizard to:– Create a broker configuration– Add a database to a broker configuration

• Primary database must be started with an SPFILE.

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Creating a Configuration

Click “Add Standby Database” to start the wizard.

Creating a ConfigurationYou can access the Data Guard features in Enterprise Manager by clicking Setup and Manage in the Data Guard section of the Maintenance page.If your primary database is not already in a broker configuration, an information page appears with this indication. Click the Add Standby Database link to invoke the Add Standby Database Wizard.Using the Add Standby Database Wizard, you perform the following steps:

1. Specify the backup type to use for the standby database creation.2. Specify the backup options.3. Select the Oracle home in which to create the standby database.4. Specify the location for standby database files.5. Specify standby database configuration parameters.6. Review the configuration information.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Creating a Configuration (continued)During the standby creation process, the following operations are performed:

• The control file, data files, and archived redo log files are backed up to a temporary location on the primary host.

• The backup pieces from the primary host are transferred to a temporary location on the standby host.

• Additional required files, such as initialization parameter and password, are created on the standby host.

• The control file, data files, and archived redo log files are restored to the specified locations on the standby host.

• Online log files and other files are added to the standby database as needed.• The recovered database is changed into a physical or logical standby.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using the Add Standby Database Wizard

Using the Add Standby Database WizardThe Add Standby Database Wizard begins by asking you to select the type of standby database that you want to create. You can create a new physical or logical standby database. Or you can add an existing database, including a RAC database, to the configuration to serve as a standby database.Note: You must be connected to the primary database with SYSDBA credentials to invoke the Add Standby Database Wizard.If you choose to create a new standby database, the following conditions are verified when you click Continue:

• All databases in the configuration are using a server parameter file (SPFILE).• The primary database is in ARCHIVELOG mode.• The COMPATIBLE initialization parameter for the primary database has a setting

of 9.0 or higher.If any of these conditions are not met, the wizard returns a message indicating that you must cancel the wizard and perform the appropriate action to meet the condition.In addition, the wizard verifies that the primary database is in FORCE LOGGING mode. If it is not in FORCE LOGGING mode, a warning message appears. You can then cancel the configuration and enable FORCE LOGGING (as described earlier in this lesson).

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 1: Specify the Backup Type

Step 1: Specify the Backup TypeYou can use the Backup Type page of the wizard to select the type of backup for creation of the standby database:

• “Perform a live backup of the primary database”: Creates a new backup using the Recovery Manager utility (RMAN)

• “Use 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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 2: Specify the Backup Options

Step 2: Specify the Backup OptionsIf you selected the “Perform a live backup of the primary database” option on the Backup Type page, you can specify a location on the primary database host to store the backup files. A default location is specified in the 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 creation” option. Otherwise, you should select the “Delete directory after standby creation” option. Note

• If you choose to retain the backup, additional space is required (as indicated on the Backup Options page). If you selected the “Use 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 a previous standby database creation and must be of the same type that you are creating.Specify the operating system credentials of the user who owns the primary database Oracle server installation in the Primary Host Credentials section.

• The credentials are preset to the host-preferred credentials that are stored with the primary database-preferred credentials by default.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 3: Select the Standby Database Location Instance Name

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 3: Select the Standby Database Location Oracle Home

Step 3: Select the Standby Database Location Oracle HomeThe Standby Database Location section lists all the available Oracle homes that match the primary database version and host operating system. From this list, select the host and Oracle home for your new standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 4: Specify the Standby Database File Locations Access Method

Step 4: Specify the Standby Database File Locations Access MethodThe 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.

• Transfer files: If you choose to transfer files from the primary host working directory to a standby host directory, you must specify a temporary location on the standby host to store the backup files copied from the primary host. In addition, you must select the file transfer method: FTP or HTTP server. FTP is the faster of the two file transfer methods. Select the HTTP Server option if you know that the primary 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 4: Specify the Standby Database File Locations File Locations

Step 4: Specify the Standby Database File Locations File LocationsBy default, all standby database files are placed in an Oracle Optimal Flexible Architecture (OFA) directory structure when your primary and standby databases are on the same host.When your primary and standby databases are on different hosts, you can specify that you want to convert the standby files to an OFA structure or keep the file names and locations the same as the primary database. You can optionally change the locations of individual standby database files by clicking the Customize button to display the File Locations Customize page of the wizard.Data Guard automatically adds configuration information for the new standby database to the listener.ora and tnsnames.ora files in the directory that is specified in the Configuration File Location field in the Network Configuration File Location section. The default location is the network administration directory 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 running in a different Oracle home on the standby host.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 5: Specify Standby Database Configuration Parameters

Step 5: Specify Standby Database Configuration ParametersOn the Standby Configuration page of the wizard, you can specify configuration parameters for the standby database. The parameters that must be specified depend on whether you are adding an existing standby database, creating a new physical standby database, or creating a new logical standby database. The configuration parameters include the instance name, service provider name, target name, and standby archive location. The default values are based on corresponding primary database settings.When you create a new physical database, the following parameters must be configured:

• Database Unique Name: Specify a value for the database DB_UNIQUE_NAME parameter. This name must be unique within the Data Guard configuration. Note: This field appears only if you are creating a new physical standby database and the primary database is an Oracle10g database.

• Target Name: Specify a name for Enterprise Manager to use for the new standby database. This name will appear in the list of database targets maintained by Enterprise Manager. This name should be the same as the database unique name.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 6: Review the Configuration Information

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Standby Database Creation: Processing

Standby Database Creation: ProcessingYou can view the progress of the Add Standby Database process on the Processing page. On completion of the process, Oracle Enterprise Manager displays the Data Guard Overview page.The display on the Processing page differs based on whether you are adding an existing standby database or creating a new standby database. An arrow icon indicates which step is being processed. When it completes, a check icon appears next to the step. The following steps appear on the Processing page:

• Creating Data Guard Configuration or Updating Data Guard Configuration: The Data Guard configuration is created during this step if it does not exist. If you are adding an existing standby database, it is added to the configuration.

• Preparing standby creation job: This step appears only if you are creating a new standby database. The standby database is actually created by an Enterprise Manager job; preliminary setup steps to prepare for job submission are accomplished in this step. You can cancel the Add Standby Database process at any point up to the completion of this step.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Standby Database Creation: Processing (continued)• Submitting standby creation job: This step appears only if you are creating a new standby

database. The Enterprise Manager job that creates the standby database in the background is submitted in this step. The Add Standby Database process cannot be canceled once this step begins.

• Adding standby database target: In this step, the standby database target in Enterprise Manager is updated with additional information denoting membership in the Data Guard configuration. This enables enhanced summary information to be displayed on the Enterprise Manager home page of the standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Standby Database Creation: Progress

Click “Creation in progress” to view the job.

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Standby Database Creation: Job Details

Standby Database Creation: Job DetailsYou can monitor creation of the standby database by viewing the details on the job progress page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Verifying a Configuration

Click “Verify Configuration.”

Verifying a ConfigurationAfter you create your configuration, you should use the Data Guard Verify operation to check the configuration. You can invoke the Verify operation by clicking Verify Configuration in the Additional Administration section of the Data Guard page. When you invoke the Verify operation, a series of validation checks is performed on the Data Guard configuration, including a health check of each database and each agent. The Verify operation does the following:

• Determines the current data protection mode settings, including the current redo transport mode settings for each database and whether or not the standby redo logs are configured properly. If standby redo logs are needed for any database, a message indicates this on the Detailed Results page. You can then add the standby redo logs.

• Validates each database for the current status • Performs a log switch on the primary database (for non-RAC databases) and verifies that

the log was applied on each standby database• Checks the agent status for each database. The verify process executes a SQL*Plus job on

the agent if credentials are available. If credentials are not available to run the job, the agent is pinged instead. If any errors occur during this process, a message appears on the Detailed Results page.

• Displays the results of the Verify operation, including any errors Note: You can cancel the Verify operation at any time by clicking Cancel.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Reviewing Results of the Verify Operation

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Creating Standby Redo Logs

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Viewing the Data Guard Configuration Status

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Viewing Data Guard Performance

Viewing Data Guard PerformanceYou can click Performance Overview in the Performance section of the Data Guard Overview page to access the Performance Overview page.The Performance Overview page displays detailed performance-related statistics for the Data Guard configuration. The performance charts provide a graphical summary of all redo log activity in the configuration. You can set the collection interval (which causes the charts to be refreshed) to determine the rate of sampling of the primary database in the View Data field. The Performance Overview page displays performance information for all the databases in the configuration as follows:

• Redo Generation Rate: Shows the redo generate rate in KB per second• Lag Time: Shows the approximate amount of potential data loss• Apply Rate: Displays the 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.

You can click any of the charts to obtain historical information.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to:• Enable FORCE LOGGING• Use Enterprise Manager to create a configuration• Use Enterprise Manager to monitor the configuration

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




This practice covers the following topics:• Logging in to Oracle Enterprise Manager 10g

Grid Control• Using the wizard to create a Data Guard broker

configuration with a physical standby database• Verifying the configuration

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Creating a Physical Standby Databaseby Using SQL

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be ableto use SQL commands to create a physical standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Steps to Create a Physical Standby Database

1. Prepare the primary database.2. Back up the primary database.3. Copy files to the standby system.4. Set parameters on the physical standby database.5. Start the standby database.6. Configure Oracle Net Services.7. Set parameters on the primary database.8. Start the transport of redo.

Steps to Create a Physical Standby DatabasePerform the following steps to create a physical standby database by using SQL commands:

1. Prepare the primary database.2. Back up the primary database.3. Copy files to the standby system.4. Set parameters on the physical standby database.5. Start the standby database.6. Configure Oracle Net Services.7. Set parameters on the primary database.8. Start the transport of redo.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Preparing the Primary Database

• Enable FORCE LOGGING at the database level.

• Create a password file.• Set initialization parameters.• Enable archiving.

SQL> ALTER DATABASE FORCE LOGGING;

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

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting Initialization Parameters on the Primary Database

Traces redo data transmissionLOG_ARCHIVE_TRACE

Forces a log switch after the specifiednumber of seconds elapses

ARCHIVE_LAG_TARGET

Controls automatic standby file managementSTANDBY_FILE_MANAGEMENT

Converts primary database log file namesLOG_FILE_NAME_CONVERT

Converts primary database file namesDB_FILE_NAME_CONVERT

Specifies the unique database name for each database in the configuration

LOG_ARCHIVE_CONFIG

Specifies destination stateLOG_ARCHIVE_DEST_STATE_n

LOG_ARCHIVE_DEST_n

Parameter Name

Controls redo transport services

Description

Setting Initialization Parameters on the Primary DatabaseOn 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 on the following pages.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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.

• Additional LOG_ARCHIVE_CONFIG parameter values:– SEND: enables a database to send redo data to remote

destinations.– RECEIVE: enables the standby database to receive redo

from another database.– Use the NOSEND and NORECEIVE keywords to disable

these settings.

DB_NAME=chicagoDB_UNIQUE_NAME=chicagoLOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'

LOG_ARCHIVE_CONFIG

Specify the DG_CONFIG attribute on the LOG_ARCHIVE_CONFIG parameter to list the DB_UNIQUE_NAME of the primary and standby databases in the Data Guard configuration. This setting enables the dynamic addition of a standby database to a Data Guard configuration that has a Real Application Clusters primary database running in either maximum protection or maximum availability mode. By default, the LOG_ARCHIVE_CONFIG parameter enables the database to send and receive redo. After a role transition, you may need to specify these settings again using the SEND, NOSEND, RECEIVE, or NORECEIVE keywords.Note: The database must be in MOUNT mode to change the SEND, NOSEND, RECEIVE, or NORECEIVE settings.Use the V$DATAGUARD_CONFIG view to see the unique database names defined with the DB_UNIQUE_NAME and LOG_ARCHIVE_CONFIG initialization parameters, providing a view of 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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=(EDT3R7P1_SITE1,EDT3R7P1_SITE2)

SQL> select * from v$dataguard_config;

DB_UNIQUE_NAME------------------------------EDT3R7P1_ORCLEDT3R7P1_SITE1EDT3R7P1_SITE2

Note: The LOG_ARCHIVE_CONFIG initialization parameter replaces the REMOTE_ARCHIVE_ENABLE initialization parameter, which will be deprecated in a future release. Do not specify both parameters in the same SPFILE or text initialization parameter file.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



LOG_ARCHIVE_DEST_n

• Specify at least two LOG_ARCHIVE_DEST_n parameters.• Must contain (at a minimum) one of the following:

– LOCATION

– SERVICE

• LOG_ARCHIVE_DEST_STATE_n parameter for each defined destination

LOG_ARCHIVE_DEST_2='SERVICE=bostonVALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=boston'LOG_ARCHIVE_DEST_STATE_2=ENABLE

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 35 different attributes that can be set for each LOG_ARCHIVE_DEST_n parameter. Most have defaults that are adequate for most configurations. See Oracle Data Guard Concepts and Administration for a complete list and description of each. You should specify at least two LOG_ARCHIVE_DEST_n parameters (where n is an integer from 1 to 10): one parameter for the required local archiving destination and another parameter for a standby location. Query the V$ARCHIVE_DEST view to see current settings of the LOG_ARCHIVE_DEST_n initialization parameter.All LOG_ARCHIVE_DEST_n parameters must contain, at a minimum, either a LOCATION or SERVICE attribute. In addition, you must have a LOG_ARCHIVE_DEST_STATE_nparameter for each defined destination.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



LOCATION and SERVICE Attributes

Each archive log destination includes one of the following attributes:• LOCATION: specifies a valid path name.• SERVICE: specifies a valid Oracle Net Services name

referencing a standby database.

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=chicago'LOG_ARCHIVE_DEST_2='SERVICE=boston VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'

LOCATION and SERVICE AttributesEach LOG_ARCHIVE_DEST_n destination must specify either the LOCATION attribute or the SERVICE attribute to identify either a local disk directory or a remote database destination where redo transport services can transmit redo data.LOCATION: Each destination that specifies the LOCATION attribute must identify a unique directory path name. This is the local destination for archived redo logs.SERVICE: Specifies a valid Oracle Net Services name. This service may be one of the following:

• A standby database (either physical or logical)• An archive log repository, allowing for off-site archiving of redo logs. An archive log

repository is created by using a standby control file, starting the instance, and mounting the database. This destination contains no data files. Note: The Data Guard broker does not support this type of service.

• A cross-instance archival database environment is possible on both the primary and standby databases. In a RAC environment, each instance directs its archived redo logs to a single instance of the cluster. The recovery instance typically has a tape drive available to support RMAN backup and restore operations. Note: The Data Guard broker does not support this type of service.

Note: There are no defaults for these attributes.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



LOG_ARCHIVE_DEST_STATE_n

• Defines the current state of an archive log destination:– ENABLE (default)– DEFER

– RESET

• Applies to the primary and standby database

log_archive_dest_3='SERVICE=stby1_path1 ALTERNATE=LOG_ARCHIVE_DEST_4'log_archive_dest_4='SERVICE=stby1_path2'log_archive_dest_state_3=ENABLE

LOG_ARCHIVE_DEST_STATE_n

The LOG_ARCHIVE_DEST_STATE_n initialization parameter (where n is an integer from 1 to 10) specifies the state of the corresponding destination that is indicated by the LOG_ARCHIVE_DEST_n initialization parameter (where n is the same integer). For example, the LOG_ARCHIVE_DEST_STATE_2 parameter specifies the state of the LOG_ARCHIVE_DEST_2 destination. The following are the valid values:• ENABLE: specifies that a valid log archive destination can be used for a subsequent

archiving operation (automatic or manual). This is the default.• DEFER: specifies that valid destination information and attributes are preserved but that the

destination is excluded from archiving operations until re-enabled.• RESET: functions similarly to DEFER but clears any error messages for the destination if it

had previously failed.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Specifying Values for DB_FILE_NAME_CONVERT

• Must be defined on standby databases that have different disk or directory structures from the primary

• Allows multiple pairs of file names• Applies to a database when in physical standby mode

DB_FILE_NAME_CONVERT =('/oracle1/dba/','/ora1/stby_dba/','/oracle2/dba/','/ora2/stby_dba/')

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Specifying Values for LOG_FILE_NAME_CONVERT

• Similar to DB_FILE_NAME_CONVERT• Must be defined on standby databases that have

different disk or directory structures from the primary• Online redo log files are used only when the standby

becomes a primary.• Applies to a database when in physical standby mode

LOG_FILE_NAME_CONVERT = ('/oracle1/logs/','/ora1/stby_logs/')

Specifying Values for LOG_FILE_NAME_CONVERTThe 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.Note: If the standby database uses OMF, do not set the LOG_FILE_NAME_CONVERTparameter.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Specifying a Value for LOG_ARCHIVE_FORMAT

• Indicates the format for redo log file names• Format directives:

– %t: Thread number– %T: Zero-filled thread number– %s: Sequence number– %S: Zero-filled sequence number– %d: Database ID– %D: Zero-filled database ID – %a: Current activation ID– %A: Zero-filled activation ID– %r: Resetlogs ID

• Default value is operating-system dependent.

LOG_ARCHIVE_FORMAT = %d_%t_%s_%r.arc

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Specifying a Value for STANDBY_FILE_MANAGEMENT

• Used to maintain consistency when you add or delete a data file on the primary database– MANUAL (default)

— Data files must be manually added to the standby database.– AUTO

— Adds the data file automatically to the standby database— Certain ALTER statements are no longer allowed on the standby

database.

• Applies to the primary database and physical standby database

STANDBY_FILE_MANAGEMENT = auto

Specifying a Value for STANDBY_FILE_MANAGEMENTWhen STANDBY_FILE_MANAGEMENT is set to AUTO, you cannot execute the following commands on the standby database:• ALTER DATABASE RENAME• ALTER DATABASE ADD/DROP LOGFILE [MEMBER]• ALTER DATABASE ADD/DROP STANDBY LOGFILE MEMBER• ALTER DATABASE CREATE DATAFILE AS ...

When you add (or drop) a log file to the primary and want to add (or drop) it to the physical standby database as well, you must do the following:

• Set STANDBY_FILE_MANAGEMENT to MANUAL on the physical standby database.• Add (or drop) the redo log files on the primary database.• Add (or drop) them to the standby database.• Reset to AUTO afterward on the standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



ARCHIVE_LAG_TARGET

• Configure on primary database only• Set to the number of seconds after which a log switch

must happen even if the log file is not full• Sets maximum time that a standby database must wait

to process the redo• Default is 0 (disabled)• Range of values: 60 to 7,200• Recommended value: 1,800 (30 minutes)

ARCHIVE_LAG_TARGET = 1800

ARCHIVE_LAG_TARGET

The ARCHIVE_LAG_TARGET parameter defines the mean time to failover in the event your primary database fails and you must fail over to the standby. Although the redo is transmitted to the standby during normal operations, it is not applied to the standby database until the online redo log file on the primary has been completed.Note: If the real-time apply feature is enabled, log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. Real-time apply is described in detail in the lesson titled “Understanding the Oracle Data Guard Architecture.”For example, in a configuration where the online redo log file is 100 MB and 80 MB has been written, a failure at this point would mean that the 80 MB of redo must be applied to the standby before the failover can complete. If you need to limit the amount of time it takes to complete the failover, you can define this parameter to force a log switch after a certain amount of time, thereby enabling the redo to be applied.If you set this parameter to too small a value, the primary database log files switch too often and thus impact performance.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



LOG_ARCHIVE_TRACE Parameter

• LOG_ARCHIVE_TRACE is optional and is used for diagnostic purposes.

• Set this parameter to an integer value to see the progression of the archiving of redo logs to the standby system.– On the primary 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 located in the directory specified by the USER_DUMP_DEST parameter.

LOG_ARCHIVE_TRACE ParameterYou can set this parameter to trace the transmission of redo data to the standby system. To enable, disable, or modify the LOG_ARCHIVE_TRACE parameter in a primary database, do one of the following:

• Shut down the primary database, modify the initialization parameter file, and restart the database.

• Issue an ALTER SYSTEM SET LOG_ARCHIVE_TRACE=trace_level statement while the database is open or mounted.

If you change the value of this parameter dynamically with an ALTER SYSTEM statement, the changes take effect at the start of the next archive operation.Refer to Oracle Data Guard Concepts and Administration for additional information.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


LOG_ARCHIVE_TRACE Parameter (continued)The integer values for the LOG_ARCHIVE_TRACE parameter represent levels of tracing data. In general, the higher the level, the more detailed the information. You can combine tracing levels by setting the value of the LOG_ARCHIVE_TRACE parameter to the sum of the individual levels. For example, setting the parameter to 6 generates level 2 and level 4 trace output.The following integer levels are available:

Level Meaning 0 Disables archived redo log tracing (default setting) 1 Tracks archiving of redo log file 2 Tracks archival status per archived redo log destination 4 Tracks archival operational phase 8 Tracks archived redo log destination activity 16 Tracks detailed archived redo log destination activity 32 Tracks archived redo log destination parameter modifications 64 Tracks ARCn process state activity 128 Tracks FAL server process activity 256 Reserved for future use 512 Tracks asynchronous LGWR activity 1024 Tracks RFS physical client 2048 Tracks ARCn or RFS heartbeat 4096 Tracks real-time apply activity 8192 Tracks Redo Apply activity (media recovery or physical

standby)

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Example: Setting Initialization Parameters on the Primary Database

DB_NAME=chicagoDB_UNIQUE_NAME=chicagoSERVICE_NAMES=chicagoLOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl'LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/VALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=chicago'LOG_ARCHIVE_DEST_2='SERVICE=bostonVALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=boston'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLEREMOTE_LOGIN_PASSWORDFILE=EXCLUSIVELOG_ARCHIVE_FORMAT=%t_%s_%r.arc

Setting Initialization Parameters on the Primary DatabaseIn the example in the slide, assume that the primary database is named chicago and the standby is named boston. For each, there is an Oracle Net Services name defined. There are additional parameters you need to add that control the receipt of the redo data and log apply services when the primary database is transitioned to the standby role:

FAL_SERVER=bostonFAL_CLIENT=chicagoDB_FILE_NAME_CONVERT='/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/'LOG_FILE_NAME_CONVERT='/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chicago/'STANDBY_FILE_MANAGEMENT=AUTO

Specifying these initialization parameters configures the primary database to resolve gaps, converts new data file and log file path names from a new primary database, and archives the incoming redo data when this database is in the standby role.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Backing Up the Primary Database by Using RMAN

RMAN> BACKUP DATABASE

• Create a backup copy of the primary database.• Use of RMAN is recommended.

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Creating a Control File for the Standby Database

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE 2 AS '/tmp/boston.ctl';

Create a control file on the primary database to be used for the standby database:

Creating a Control File for the Standby DatabaseOn the primary database, you create the control file for the standby database. Create the control file by issuing the following command:

ALTER DATABASE CREATE STANDBY CONTROLFILE AS file_name [REUSE];

If the file already exists, you can use the REUSE option to overwrite it.Note: You cannot use a single control file for both the primary and standby databases.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Copying Files to the Standby Database System

Copy the following files to the standby database system:• Backup of the data files• Standby control file• Initialization parameter file

Primary Standby

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Oracle Managed Files (OMF) and Automatic Storage Management (ASM)

• OMF: Use same on each database.• ASM: Use the RMAN DUPLICATE … FOR STANDBY

command.

OMF primary

OMF standby

Oracle Managed Files (OMF) and Automatic Storage Management (ASM)If the primary database is configured to use OMF, Oracle recommends that the standby database be configured to use OMF as well. To do this, set the DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n initialization parameters to appropriate values. Maintenance and future role transitions are simplified if the same disk group names are used for both the primary and standby databases.On the standby database, do the following:

1. If the standby database is going to use ASM, create an ASM instance if one does not already exist on the standby database system.

2. Use the RMAN BACKUP command to create a backup set that contains a copy of the primary database’s data files, archived log files, and a standby control file.

3. Use the RMAN DUPLICATE … FOR STANDBY command to copy the data files, archived redo log files, and standby control file in the backup set to the standby database’s storage area. The DUPLICATE … FOR STANDBY command performs the actual data movement at the standby instance.

For more information about OMF and ASM, see the Oracle Database Administrator’s Guide. For more information about the DUPLICATE … FOR STANDBY command, see the Oracle Database Recovery Manager Reference.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting Initialization Parameters on the Standby Database

DB_NAME=chicagoDB_UNIQUE_NAME=bostonSERVICE_NAMES=bostonLOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl'DB_FILE_NAME_CONVERT= '/arch1/chicago/','/arch1/boston/', '/arch2/chicago/','/arch2/boston/'LOG_FILE_NAME_CONVERT='/arch1/chicago/','/arch1/boston/', '/arch2/chicago/','/arch2/boston/'LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc

Continued on the next page…

Setting Initialization Parameters on the Standby DatabaseCreate a text initialization parameter file (PFILE) from the server parameter file (SPFILE) that is used by the primary database. A PFILE can be copied to the standby location and modified. Issue the following command to create the PFILE:

SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;

Later, you will convert this file back to a SPFILE after it is modified to contain the parameter values that are appropriate for use with the physical standby database.Although most of the initialization parameter settings in the text initialization parameter file that you copied from the primary system are also appropriate for the physical standby database, some modifications need to be made. The lines in italic in the slide indicate the parameters that need to be changed for use with the physical standby. The parameters shown are valid for the boston database when it is running in either the primary or the standby database role.In addition, ensure that the COMPATIBLE initialization parameter is set to the same value on both the primary and standby databases. If the values differ, redo transport services may be unable to transmit redo data from the primary database to the standby databases. In a Data Guard configuration, COMPATIBLE must be set to a minimum of 9.2.0.1.0. However, if you want to take advantage of new Oracle Database 10g features, set the COMPATIBLE parameter to 10.1.0.0 or higher.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting Initialization Parameters on the Standby Database

LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'LOG_ARCHIVE_DEST_2= 'SERVICE=chicago VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_STATE_2=ENABLEREMOTE_LOGIN_PASSWORDFILE=EXCLUSIVESTANDBY_FILE_MANAGEMENT=AUTOINSTANCE_NAME=bostonFAL_SERVER=chicagoFAL_CLIENT=boston

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Specifying a Value for STANDBY_ARCHIVE_DEST

• Defines the standby database directory where the archived redo log files are created

• Overrides the directory location that is specified with the LOG_ARCHIVE_DEST_n parameter

STANDBY_ARCHIVE_DEST = '/standby/arc_dest/'

STANDBY_ARCHIVE_DEST = 'LOCATION=/standby/arc_dest/'

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting Up the Environment to Support the Standby Database

1. If creating a standby database on a Windows platform, create a Windows-based service.

2. Create a password file.3. Configure listeners for the primary and standby

databases.

Setting Up the Environment to Support the Standby Database1. If the standby system is running on a Windows-based system, use the ORADIM tool to

create a Windows service and password file. Here is an example:WINNT> oradim -NEW -SID boston -INTPWD password -STARTMODE manual

Refer to Oracle Database Platform Guide for Windows for more information about using the ORADIM tool.

2. On platforms other than Windows, create a password file and set the password for the SYSuser to the same password that is used by the SYS user on the primary database. The password for the SYS user on every database in a Data Guard configuration must be identical for redo transmission to succeed. Refer to the Oracle Database Administrator’s Guide for information about creating a password file.

3. On both the primary and standby sites, use Oracle Net Manager to configure a listener for the respective databases. To restart the listeners so that they recognize the new definitions, enter the following Listener Control utility commands on both the primary and standby systems:

% lsnrctl stop% lsnrctl start

Refer to the Oracle Net Services Administrator’s Guide for additional information about the Listener Control utility.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting Up the Environment to Support the Standby Database

4. Create Oracle Net Services names.5. Create a server parameter file for the standby

database.

Setting Up the Environment to Support the Standby Database (continued)4. On both the primary and standby systems, use Oracle Net Manager to create a network

service name for the primary and standby databases that will be used by redo transport services. The Oracle Net Services name must resolve to a connect descriptor that uses the same protocol, host address, port, and SID that you specified when you configured the listeners for the primary and standby databases. The connect descriptor must also specify that a dedicated server be used. Refer to the Oracle Net Services Administrator’s Guide and the Oracle Database Administrator’s Guide.

5. On an idle standby database, use the CREATE SPFILE SQL statement to create a server parameter file for the standby database from the text initialization parameter file that was edited earlier, as shown in the following example:

SQL> CREATE SPFILE FROM PFILE='initboston.ora';

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Starting the Physical Standby Database

To start the physical standby database:1. Bring it to the OPEN READ ONLY stage.2. Start Redo Apply.3. Test archival operations to the physical standby

database:

SQL> STARTUP;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY

2 DATABASE DISCONNECT FROM SESSION;

Starting Up the Physical Standby Database1. On the standby database, issue the STARTUP SQL statement to start the instance and open

the database in read-only mode.2. On the standby database, issue the ALTER DATABASE RECOVER MANAGED STANDBYDATABASE SQL command to start Redo Apply. This statement automatically mounts the database. Also, include the DISCONNECT FROM SESSION option so that Redo Apply runs in a background session.

3. The transmission of redo data to the remote standby location does not occur until after a log switch. Issue the following command on the primary to force a log switch:

SQL> ALTER SYSTEM SWITCH LOGFILE;

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Additional Configuration Tasks

Perform the following tasks as appropriate for your configuration:• Configure standby redo logs.• Enable real-time apply.• Enable Flashback Database.• Upgrade the data protection mode.

Additional Configuration TasksPerform the following tasks if they are appropriate for your physical standby database:

• Configure standby redo logs: Standby redo logs are required for standby databases running in the maximum protection mode and maximum availability mode. However, configuring standby redo logs is recommended on all standby databases because, during a failover, Data Guard can recover and apply more redo data from standby redo log files than from the archived redo log files alone. The standby redo logs should exist on both primary and standby databases and have the same size and names.

• Enable real-time apply: When you enable the 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. Refer to the lesson titled “Understanding the Oracle Data Guard Architecture” for additional information about configuring real-time apply.

• Enable Flashback Database: Flashback Database removes the need to re-create the primary database after a failover. Flashback Database is similar to conventional point-in-time recovery in its effects, enabling you to return a database to a recent-past state. Flashback Database is faster than point-in-time recovery because it does not require restoring data files from backup or the extensive application of redo data. You can enable Flashback Database on the primary database, on the standby database, or on both.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Additional Configuration Tasks (continued)• Upgrade the data protection mode: The Data Guard configuration is initially set up in the

maximum performance mode (the default). Protection modes are discussed in detail in the lesson titled “Configuring Data Protection Modes and Redo Transport Services.”

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Special Note:Standby Database on the Same System

• Standby database data files must be at a different location.

• Each database instance must archive to different locations.

• Service names must be unique.• The standby database does not protect against

disaster.

Primary Standby /oracle/dba /oracle/standby/dba

Special Note: Standby Database on the Same SystemIf you have a standby database on the same system as the primary database, you must consider the following:

• The data files must be renamed. The actual file names can be the same, but at least the directory path must be different. This means that you must use the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters. Note: If the standby database uses Oracle Managed Files (OMF), do not set the DB_FILE_NAME_CONVERT or LOG_FILE_NAME_CONVERT parameter.

• 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 a total loss of the primary database system. If the standby database is on the same system, it will be lost as well. This configuration should be used for testing and training purposes only.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to:• Create a physical standby with SQL commands• Enable FORCE LOGGING• Back up the primary database• Copy files to the standby system• Set parameters on the physical standby database• Start the standby database• Configure Oracle Net Services• Set parameters on the primary database• Start the transport of redo

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Configuring Data Protection Modesand Redo Transport Services

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to do the following:• Describe the data protection modes• Change the data protection mode of your configuration• Modify redo transport services to serve your needs

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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 you set up the redo transport mode, you can put the configuration into the desired data protection mode. The data protection mode setting causes internal rules to be implemented, ensuring that your configuration is protected at the level you desire.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Defining the Redo Transport Mode

Use the attributes of LOG_ARCHIVE_DEST_n:• ARCH and LGWR

– Specify that either the archiver process or the log writer process is responsible for transmitting redo to the standby destination

– ARCH is the default.• SYNC and ASYNC (LGWR only)

– Specify that network I/O operations are to be performed synchronously or asynchronously when using LGWR

– SYNC is the default.• AFFIRM and NOAFFIRM

– Ensure that redo has been successfully written to disk on the standby destination

– NOAFFIRM is the default.

Attributes of LOG_ARCHIVE_DEST_nThe 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:• ARCH: Indicates that redo logs are transmitted to the destination during an archival

operation. A foreground archival operation or the archiver background processes (ARCn) serve as the redo log transport service. This is the default.

• LGWR: Indicates that redo is transmitted to the destination concurrently while the online redo log is being written. The log writer process (LGWR) submits the redo data to one or more network server (LNSn) processes, which then initiate the network I/O in parallel to multiple remote destinations. If a LGWR destination fails, the destination automatically reverts to using the archiver process until the error is corrected. With the LGWR attribute, you have the following additional options:

- SYNC: Specifies that network I/O is to be performed synchronously for the destination, meaning that once the I/O is initiated, the log writer process waits for the I/O to complete before continuing.

- ASYNC: Specifies that network I/O is to be performed asynchronously for the destination. In ASYNC mode all network I/O is done completely independent of the LGWR process. Use of the ASYNC attribute allows standby environments to be maintained with little or no performance impact on the primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Attributes of LOG_ARCHIVE_DEST_n (continued)• AFFIRM: ensures that all disk I/O to the archived redo log files or standby redo log files at

the standby destination is performed synchronously and completes successfully. This attribute has the potential to affect primary database performance. When you use the LGWR, SYNC, and AFFIRM attributes, the transaction is not committed until the disk I/O is completed.

• NOAFFIRM: indicates that all redo disk I/O operations are to be performed asynchronously, which means that the log writer process does not wait until the disk I/O has completed before continuing. This is the default.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting the Redo Transport Mode

Click Edit to access the Edit Standby Database Properties

page.

Setting the Redo Transport ModeUse the following procedure to set the redo transport mode by using Enterprise Manager:

1. Select your standby database, and then click Edit on the Data Guard page.2. Click “Standby Role Properties” on the Edit Standby Database Properties page.3. Click “Show Advanced Properties.”

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting the Redo Transport Mode

Select the mode from the Log Transport

Mode list.

Setting the Redo Transport Mode (continued)You can use the drop-down list to select the redo transport mode on the Standby Role Properties page. The values in the Log Transport Mode list are defined as follows: • ARCH: configures redo transport services for your standby database using the ARCH

attribute of the LOG_ARCHIVE_DEST_n initialization parameter. You do not need standby redo log files for this mode. This mode enables the lowest grade of protection to the primary database as well as the lowest performance impact.

• ASYNC: configures redo transport services for your standby database using the LGWR, ASYNC, and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode, along with standby redo log files, enables a moderate grade of protection to the primary database and incurs a lower performance impact.

• SYNC: configures redo transport services for your standby database using the LGWR, SYNC, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode, along with standby redo log files, is required for the maximum protection or maximum availability protection modes. This redo transport mode enables the highest grade of data protection to the primary database, but it also incurs the highest performance impact.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Data Protection Modes

• Three data protection modes:– Maximum protection– Maximum availability– Maximum performance

• Help to balance data availability and system performance

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Maximum Protection

• Enables zero data loss• Redo data must be written to both the local online redo

log and the standby redo log on at least one standby database.

• Primary database shuts down if a fault prevents it from writing its redo stream to at least one remote standby redo log.

• Configuration requirements:– Standby redo log files on at least one standby database– SYNC, LGWR, and AFFIRM attributes

for at least one standby database

Maximum ProtectionThis protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and the standby redo log on at least one standby database before the transaction commits. To ensure that data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to at least one remote standby redo log. For multiple-instance RAC databases, Data Guard shuts down the primary database if it is unable to write the redo records to at least one properly configured database instance.To enable maximum protection mode, perform the following configuration tasks:

• Configure standby redo log files on at least one standby database. • Set the SYNC, LGWR, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter

for at least one standby database destination.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Maximum Availability

• Enables zero data loss• Provides the highest possible level of data protection

without compromising the availability of the primary database

• Redo data must be written to both the local online redo log and the standby redo log on at least one standby database.

• Primary database does not shut down if a fault prevents it from writing its redo stream.

• Configuration requirements:– Standby redo log files on at least one standby database– SYNC, LGWR, and AFFIRM attributes

for at least one standby database

Maximum AvailabilityThis protection mode provides the highest possible level of data protection without compromising the availability of the primary database. Like maximum protection mode, a transaction will not commit until the redo needed to recover that transaction is written to the local online redo log and to at least one remote standby redo log. Unlike maximum protection mode, the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database operates in maximum performance mode until the fault is corrected and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode.This mode guarantees that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.To enable maximum availability mode, perform the following configuration tasks:

• Configure standby redo log files on at least one standby database. • Set the SYNC, LGWR, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter

for at least one standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Maximum Performance

• Default level of data protection• 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 stream is written asynchronously with respect to the commitment of the transactions that create the redo data.

Maximum PerformanceThis protection mode (the default) provides the highest possible level of data protection without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database’s redo data stream is also written to at least one standby database, but that redo stream is written asynchronously with respect to the commitment of the transactions that create the redo data.When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database performance.The maximum performance mode enables you to either set the LGWR and ASYNC attributes or set the ARCH attribute on the LOG_ARCHIVE_DEST_n parameter for the standby database destination. If the primary database fails, you can reduce the amount of data that is not received on the standby destination by setting the LGWR and ASYNC attributes.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting the Data Protection Mode

Click the Protection Mode link.

Setting the Data Protection ModeIf the data protection mode that you need requires a standby database to use the SYNC or ASYNCredo transport mode, Enterprise Manager will automatically set 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 needed for all databases in the configuration and adds those log files using the directory locations you specify.After you upgrade the protection mode using Enterprise Manager, the primary database will be restarted automatically. The primary database need not be restarted following a downgrade of the protection mode.You can set the data protection mode by using Enterprise Manager as follows:

1. Navigate to the Data Guard page.2. Click the link in the Protection Mode field to access the Change Protection Mode: Select

Mode page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting the Data Protection Mode

Setting the Data Protection Mode (continued)3. Select Maximum Protection, Maximum Availability, or Maximum Performance, and then

click Continue.4. If prompted, enter the username and password of a user with SYSDBA privileges, and then

click Login.5. Select one or more standby databases to support the protection mode that you selected. If

standby redo log files are needed, verify the names of the log files. Click OK.6. On the Confirmation page, click Yes.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting the Data Protection Mode by Using the CLI

1. Configure standby redo logs.2. Set the LogXptMode property (if necessary).3. Set the data protection mode.

DGMGRL> EDIT DATABASE 'site1_edrsr8p1' SET PROPERTY 'LogXptMode'='SYNC';DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

Setting the Data Protection Mode by Using the CLI1. If you are setting the protection mode to maximum protection or maximum availability,

ensure that standby redo log files are configured on the standby database. You must also configure standby redo log files for the primary database or another standby database in the configuration to ensure that it can support the chosen protection mode after a switchover.

2. Use the EDIT DATABASE SET PROPERTY command to set the 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 as follows:

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, issue the following command:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting the Protection Mode by Using SQL

• You must set attributes to support the type of protection desired.

• Issue the ALTER DATABASE statement on the primary database:

ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;

Setting the Protection Mode by Using SQLYou must set attributes of the LOG_ARCHIVE_DEST_n initialization parameter for each level of protection. For each level of protection, you must have at least one standby database with the following:

• Maximum protection: LGWR, SYNC, AFFIRM, and standby redo logs files• Maximum availability: LGWR, SYNC, AFFIRM, and standby redo logs files for physical

standby databases• Maximum performance: Any combination of LGWR or ARCH

Using the following SQL statement on the primary database, you can configure the Data Guard environment to maximize data protection, availability, or performance:ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Delaying the Application of Redo

Delaying the application of redo helps safeguard against:• Data corruption• User errors

Productiondatabase

Standbydatabase

Ora

cle

Net Delayed

application

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Enterprise Manager to Delay the Application of Redo

Specify the delay in minutes.

Using Enterprise Manager to Delay the Application of RedoYou can configure delayed apply by using Enterprise Manager as follows:

1. On the Data Guard page, select your standby database. Then click Edit.2. On the Edit Standby Database Properties page, click Standby Role Properties.3. In the Apply Delay field, enter the delay value (in minutes). 4. Click Apply.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting LOG_ARCHIVE_DEST_nto Delay the Application of Redo

Use the attributes of LOG_ARCHIVE_DEST_n to control the application of redo:• DELAY: number of minutes to delay application of redo

(default: 30 minutes)

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Flashback Database Instead of Apply Delay

No delay

4-hour delay

Standby1

Standby2

Standby3

8-hour delay

Standby

Primary database

Primary database

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Additional Attributes That Affect Redo Transport Services

• ALTERNATE

• DEPENDENCY

• MAX_FAILURE

• NET_TIMEOUT

• REOPEN

Additional Attributes That Affect Redo Transport ServicesThe following pages present additional attributes of the LOG_ARCHIVE_DEST_n initialization parameter that affect redo transport services. The use of each attribute depends entirely on your individual business requirements.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using the ALTERNATE Attribute

• Can specify one alternate destination for the LOG_ARCHIVE_DEST_n parameter

• Allow a failed destination to change destinations– Disk full: switch to new disk– Oracle Net link fails: switch to new network link

• Require REOPEN=0 or MAX_FAILURE• Enabled with LOG_ARCHIVE_DEST_STATE_n

log_archive_dest_3='SERVICE=stby1_path1 REOPEN=0 ALTERNATE=LOG_ARCHIVE_DEST_4'log_archive_dest_4='SERVICE=stby1_path2 REOPEN=0 OPTIONAL'log_archive_dest_state_3=ENABLElog_archive_dest_state_4=ALTERNATE

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using the MAX_FAILURE Attribute

MAX_FAILURE[=count]

• Number of times redo transport services attempts to reestablish communication

• Requires REOPEN• No default count

log_archive_dest_3='SERVICE=o10g1 LGWR MAX_FAILURE=30 REOPEN'

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using the NET_TIMEOUT Attribute

• Enables the LGWR process to avoid a network timeout issue

• Valid with SYNC or ASYNC destinations• Value supplied is the number of seconds to wait.• Range of values for NET_TIMEOUT: 15 to 1200• Default: 180• Use caution in maximum protection mode.

log_archive_dest_2='SERVICE=o10g2 LGWR SYNC NET_TIMEOUT=30'

Using the NET_TIMEOUT AttributeThe NET_TIMEOUT attribute enables you to bypass the default network timeout interval established for the system on which the primary database resides. Without the NET_TIMEOUTattribute, 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using the REOPEN Attribute

• REOPEN[=seconds]

– Minimum number of seconds to wait before retrying a failed destination at log switch

– Failures can be network failures, quota exceptions, disk full, and so on.

– Default: 300 seconds (5 minutes)• REOPEN=0

– Failed destinations remain disabled until:— Manually reenabled— ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE

issued— Instance restart

– Required when using ALTERNATE destinations with MAX_FAILURE=0 attributes

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Optimized Asynchronous Redo Transmission

LGWR

Primary database

transactions

Onlineredologs

ARC0FAL

RFS

MRP or LSP

Archived redo logs

(MRP only)

Archived redo logs

ARC1ARC2

LNSn

Ora

cle

Net

Reports

Backup

Standbydatabase

Optimized Asynchronous Redo TransmissionIn Oracle Database 10g Release 2, the redo transport mechanism is enhanced to more effectively utilize all of the available bandwidth. A single, large redo log file may be transferred in parallel by multiple ARCn processes. 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Enabling Multiple Connectionsfor Remote Archival of Redo

LOG_ARCHIVE_DEST_3='SERVICE=detroit MAX_CONNECTIONS=5'

The following conditions must be met to enable this feature:• Remote archiving is performed to disk.• LOG_ARCHIVE_LOCAL_FIRST must be set to TRUE

(default).

Enabling Multiple Connections for Remote Archival of RedoThe 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 isestablished 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 will use the available ARCn processes.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to:• Describe the data protection modes• Change the data protection mode of your configuration• Modify redo transport services to suit your needs• Delay the application of redo• Use additional transport services attributes

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




This practice covers the following topics:• Changing the data protection mode• Delaying the application of redo

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Creating a Logical Standby Database by Using Enterprise Manager

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to do the following:• Explain the advantages of SQL Apply • Explain when to use a logical standby database• Create a logical standby database by using Enterprise

Manager

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Benefits of Implementing aLogical Standby Database

• 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 DatabaseA logical standby database provides disaster recovery, high availability, and data protection benefits that are similar to those of a physical standby database. It also provides the following specialized benefits:

• Efficient utilization of system resources: A logical standby database is an open, independent, and active production database. It can host multiple database schemas, and users can perform normal data manipulation operations on tables in schemas that are not updated from the primary database. It remains open while the tables are updated from the primary database, and those tables are simultaneously available for read-access. Because the data can be presented with a different physical layout, additional indexes and materialized views can be created to improve your reporting and query requirements and to suit your specific business requirements.

• Reduction in primary database workload: The logical standby tables that are updated from the primary database can be used for other tasks (such as reporting, summations, and queries), thereby reducing the primary database workload.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Benefits of Implementing aLogical Standby Database

• Provides data protection: – Primary database corruptions not propagated

• Provides disaster recovery capabilities:– Switchover and failover– Minimizes downtime for planned and unplanned outages

Benefits of Implementing a Logical Standby Database (continued)• Data protection: A logical standby database provides a safeguard against data corruptions

and user errors. Primary-side physical corruptions do not propagate through the redo datathat are transported to the logical standby database. Similarly, user errors that may cause the primary database to be permanently damaged can be resolved before application on the logical standby through delay features.

• Disaster recovery: A logical standby database provides a robust and efficient disaster-recovery solution. Easy-to-manage switchover and failover capabilities allow easy role reversals between primary and logical standby databases, minimizing the downtime of the primary database for planned and unplanned outages.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Securing Your Logical Standby Database

• Configure the database guard to control user access to tables.

• ALTER DATABASE GUARD command keywords:– ALL: prevents users from making changes to any data in

the database.– STANDBY: prevents users from making changes to any

data maintained by Data Guard SQL Apply.– NONE: normal security

• Query GUARD_STATUS column in V$DATABASE.• Database guard level is set to ALL by broker

automatically on the logical standby database.• Database guard level applies to all users except SYS.

Securing Your Logical Standby DatabaseYou can control user access to tables in a logical standby database by using the ALTERDATABASE GUARD command to configure the database guard.By default, it is not possible for a nonprivileged user to modify data on a Data Guard SQL Apply database. This is because the database guard is automatically set to ALL. With this level of security, only the SYS user can modify data. 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 user to access the standby database as long as they have the correct privileges.When creating a logical standby database manually with SQL commands, you must issue the ALTER DATABASE GUARD ALL command before opening the database. Failure to do so will allow jobs that are submitted through DBMS_JOB.SUBMIT to be scheduled and to potentially modify tables in the logical standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Preparing to Create aLogical Standby Database

Perform the following steps on the primary database before creating a logical standby database:1. Check for unsupported data types. 2. Be aware of unsupported DDL commands.3. Ensure row uniqueness. 4. Verify that the primary database is configured for

ARCHIVELOG mode.5. Enable supplemental logging.

Preparing to Create a Logical Standby DatabaseWhen creating a logical standby database, you must take several actions before you begin. The following pages discuss these steps in detail.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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 using table compression– Tables used to support materialized views– Global temporary tables– Tables with unsupported data types (see list on next

page)

Unsupported ObjectsIf the primary database contains unsupported tables, log apply services automatically exclude these tables when applying redo data to the logical standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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– Object types REFs– Varrays– Nested tables– XMLtype

Unsupported Data TypesEnsure that your logical standby database can support the data types of the database objects that are defined in your primary database.Refer to Oracle Data Guard Concepts and Administration for additional information about unsupported data types and objects.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Checking for Tables with Unsupported Data Types

Query DBA_LOGSTDBY_UNSUPPORTED on the primary database for tables with unsupported data types:

SQL> desc DBA_LOGSTDBY_UNSUPPORTED

Name Null? Type-------------- -------- -------------OWNER NOT NULL VARCHAR2(30)TABLE_NAME NOT NULL VARCHAR2(30)COLUMN_NAME NOT NULL VARCHAR2(30)DATA_TYPE VARCHAR2(106)

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Unsupported DDL Commands

• EXPLAIN

• LOCK TABLE

• SET CONSTRAINTS

• SET ROLE

• SET TRANSACTION

• ALTER DATABASE

• ALTER SESSION

• ALTER MATERIALIZED VIEW

• ALTER MATERIALIZED VIEW LOG

• ALTER SYSTEM

• 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

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Ensuring Unique Row Identifiers

• Query DBA_LOGSTDBY_NOT_UNIQUE on the primary database to find tables without a unique identifier:

• BAD_COLUMN values:– Y: Data type is unbounded.– N: Table contains enough column information.

• Add a primary key or unique index to ensure that SQL Apply can efficiently apply data updates

SQL> desc DBA_LOGSTDBY_NOT_UNIQUEName Null? Type-------------- -------- ------------OWNER NOT NULL VARCHAR2(30)TABLE_NAME NOT NULL VARCHAR2(30)BAD_COLUMN VARCHAR2(1)

Ensuring Unique Row IdentifiersBecause 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_UNIQUE3 WHERE TABLE_NAME NOT IN 4 (SELECT TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED);

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Ensuring Unique Row Identifiers (continued)The key column in this view is BAD_COLUMN. If this view returns a row for a given table, you may want to consider adding a primary or unique key constraint on the table.A value of Y indicates that the table does not have a primary or unique constraint and that the column is defined using an unbounded data type, such as CLOB. If two rows in the table match except for values in their LOB column, then the table cannot be maintained properly and SQL Apply stops. A value of N indicates that the table does not have a primary or unique constraint but that it contains enough column information to maintain the table in the logical standby database. However, the 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 on the next page).

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Adding a Disabled Primary Key RELY Constraint

You can add a disabled RELY constraint to uniquely identify rows:

SQL> ALTER TABLE hr.employees2 ADD PRIMARY KEY (employee_id, last_name)3 RELY DISABLE;

Adding a Disabled Primary Key RELY ConstraintIf 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. Supplemental logging must be set to MINIMAL or FULL as described on the next page.Note: For this example, assume that the HR.EMPLOYEES table does not have a primary key.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Supplemental Logging

• Adds supplemental data to the log stream• Three levels of database supplemental logging:

– Full: enables database-wide, before-image logging of primary keys or unique indexes for all updates.

– Minimal: Minimal amount of information needed for LogMiner to identify, group, and merge the redo operations that are associated with DML changes.

– None: No additional redo information added to the redo stream.

• SQL Apply requires full supplemental logging.

Supplemental LoggingSupplemental logging must be enabled on the primary database to support a logical standby database. Because an Oracle Database logs only the columns that were modified, this is not always sufficient to uniquely identify the row that changed, and additional information must be put into the stream of redo data. The supplemental information that is added to the redo data helps SQL Apply correctly identify and maintain tables in the logical standby database.The supplemental_db_logging clauses of the ALTER DATABASE command instructs the Oracle Database server to add or stop adding supplemental data to the log stream.Full supplemental logging (or identification key logging) enables database-wide, before-image logging of primary keys or unique indexes (in the absence of primary keys) for all updates. With this type of logging, an application can identify updated rows logically rather than resorting to row IDs. This type of logging is required by SQL Apply.On the primary database, issue the following statement to add primary key and unique index information to the archived redo log file:

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA 2 (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

Note: The default for supplemental logging is None.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Enabling Supplemental Logging

• Data Guard broker automatically enables supplemental logging.

• Manually enable full supplemental logging before you create your logical standby:

• Verify that the following columns in V$DATABASEcontain a YES value:– SUPPLEMENTAL_LOG_DATA_MIN

– SUPPLEMENTAL_LOG_DATA_PK

– SUPPLEMENTAL_LOG_DATA_UI

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA2 (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

Enabling Supplemental LoggingYou must enable full supplemental logging before you create the logical standby database. The reason is that the logical standby database cannot use archived redo logs that contain both supplemental log data and nonsupplemental log data. Note: Enterprise Manager automatically enables supplemental logging when you create the logical standby database.The following columns in the V$DATABASE view have a YES value after supplemental logging has been enabled. YES represents the following for the respective columns:• SUPPLEMENTAL_LOG_DATA_MIN: LogMiner has sufficient information to support

chained rows and various storage arrangements.• SUPPLEMENTAL_LOG_DATA_PK: All columns of the primary key are placed in the redo

log whenever there is an update.• SUPPLEMENTAL_LOG_DATA_UI: If any unique key columns are modified, all other

columns belonging to the unique key are also logged.Note: If you enable full supplemental logging on your primary database and you have already created physical standby databases, then you must enable supplemental logging on each physical standby database to ensure that future switchovers work correctly.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Verifying Values ofInitialization Parameters

Verify the values for the following initialization parameters on the primary database :• PARALLEL_MAX_SERVERS:

– Set to 5 or greater.– Recommended value is 9.

• LOG_PARALLELISM: Set to 1 (default).• SHARED_POOL_SIZE: Set to 160 MB or greater.

Verifying Values of Initialization Parameters Verify the values of the following initialization parameters on the primary database before creating the logical standby database (where the parameters will also be applicable):• PARALLEL_MAX_SERVERS: Value must be set to 5 or greater. The recommended value is

9. The SQL Apply Service on the logical standby site uses several parallel processes when applying the SQL to the logical database.

• LOG_PARALLELISM: Value must be set to 1. This is the default value. If this value is changed, LogMiner on the logical standby site cannot read the redo logs.

• SHARED_POOL_SIZE: Value should be 160 MB or greater. This is a recommendation. Your configuration may operate with a lower value, but in a production environment a lower value may cause performance degradation.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Creating a Logical Standby Database with Enterprise Manager

Click “Add Standby Database.”

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using the Add Standby Database Wizard

Select “Create a new logical standby database.”

Using the Add Standby Database WizardSelect “Create a new logical standby database” on the Add Standby Database page, and then click Continue.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 1: Specifying the Backup Type

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 2: Specifying the Backup Options

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 3: Selecting the Database Location Instance Name

Step 3: Selecting the Database Location Instance NameOn the Database Location page, specify the parameters that are required to create the standby database and select the Oracle home in which to create the standby database. The standby database can be created in any Oracle home that has been discovered by Oracle Enterprise Manager. Only Oracle homes on hosts that match the architecture and version of the primary host are shown.Click Next to continue.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 4: Specifying the Standby Database File Locations Access Method

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 4: Specifying the Standby Database File Locations File Locations

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 5: Specifying Standby Database Configuration Parameters

Step 5: Specifying Standby Database Configuration ParametersOn the Standby Configuration page, you can specify configuration parameters for the standby database. The configuration parameters include the instance name, service provider name, target name, and standby archive location. The default values are based on corresponding primary database settings.When you create a new logical standby database, the following parameters must be configured:

• Database Name: This field appears only when you are creating a new logical standby database. (Physical standby databases use the same database name as the primary.) A default database name is provided; you can specify any name that conforms to Oracle naming conventions.

• Database Unique Name: Specify a value for the DB_UNIQUE_NAME parameter. This name must be unique in the Data Guard configuration.

• Target Name: Specify a name for Enterprise Manager to use for the new standby database. This name appears in the list of database targets maintained by Enterprise Manager. It is recommended that this name be the same as the database unique name.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 6: Reviewing the Configuration Information

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Standby Database Creation Processing

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Automatic Deletion of Redo LogFiles by SQL Apply

Logical standbydatabase

Redo logs from primary

database

Transform redo information into

SQL

Delete redo log files

SQL Apply

Automatic Deletion of Redo Log Files by SQL ApplyIn Oracle Database 10g Release 2, archived redo logs on the logical standby database are automatically deleted by SQL Apply after they have been 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Enabling and Disabling the Auto-Delete Feature

• Enabling the auto-delete feature:

• Disabling the auto-delete feature:

EXECUTE dbms_logstdby.apply_set('LOG_AUTO_DELETE','TRUE');

EXECUTE dbms_logstdby.apply_set('LOG_AUTO_DELETE','FALSE');

Enabling and Disabling the Auto-Delete FeatureYou can enable the auto-delete feature for archived redo logs with the DBMS_LOGSTDBY.APPLY_SET procedure as shown. By default, the auto-delete feature is enabled in Oracle Database 10g Release 2.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to:• Explain the advantages of a logical standby database• Decide when to use a logical standby database• Create a logical standby by using Enterprise Manager

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




This practice covers the following topics:• Creating a logical standby database using the

Add Standby Database Wizard• Verifying the configuration

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Creating a Logical Standby Databaseby Using SQL

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to use SQL commands to create a logical standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Preparing to Create aLogical Standby Database

As preparation for creating a logical standby database, perform the following steps on the primary database:• Check for unsupported data types. • Be aware of unsupported DDL commands.• Ensure row uniqueness. • Verify that the primary database is configured for

ARCHIVELOG mode.• Enable supplemental logging.• Check the values of the initialization parameters.

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Creating a Logical Standby Database

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. Convert 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 DatabaseEach of these steps is outlined in detail in the remainder of this lesson.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 1: Create a Physical Standby Database

a. Create a physical standby database.b. Ensure that the physical standby database is caught up

to the primary database.

Step 1: Create a Physical Standby DatabaseYou 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.”

b. Ensure that the physical standby database is caught up to the primary database by allowing recovery to continue until the physical standby database is consistent with the primary database, including all database structural changes (such as adding or dropping data files).

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 2: Stop Redo Apply on the Physical Standby Database

• Before converting the physical standby database to a logical standby database, stop Redo Apply.

• Required to avoid applying changes past the redo that contains the LogMiner dictionary.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY 2 DATABASE CANCEL;

Step 2: Stop Redo Apply on the Physical Standby DatabaseBefore converting the physical standby database to a logical standby database, you must stop Redo Apply by issuing the ALTER DATABASE RECOVER MANAGED STANDBY DATABASECANCEL command.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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

a. Prepare the primary database for role transitions by setting LOG_ARCHIVE_DEST_n parameters appropriately.

b. Set the LOG_ARCHIVE_DEST_3 initialization parameter for transitioning to a logical standby role.

c. Set the value of UNDO_RETENTION to 3600.

LOG_ARCHIVE_DEST_3='LOCATION=/arch/chicago/VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE)DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_STATE_3=enable

Step 3: Prepare the Primary Database to Support a Logical Standby DatabasePerform the following steps to 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.Use the ALTER SYSTEM SET SCOPE=BOTH command to dynamically set the LOG_ARCHIVE_DEST_n initialization parameters.Modify the LOG_ARCHIVE_DEST_1 parameter to be valid for (ONLINE_LOGFILES,ALL_ROLES) of the primary database.

b. To transition the primary database to a logical standby database role, include the LOG_ARCHIVE_DEST_3 destination on the primary database. This parameter takes effect only when the primary database is transitioned to the standby database role.

c. Set the UNDO_RETENTION initialization parameter to 3600. The UNDO_RETENTIONparameter 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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.

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

Step 4: Build a LogMiner Dictionary in the Redo DataSQL 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-constraint/index columns.Note: The DBMS_LOGSTDBY.BUILD procedure waits for all existing transactions to complete so long-running transactions executing on the primary database will affect its operation.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 5: Transition to a Logical Standby Database

a. Convert to a logical standby database.

b. Create a new password file.c. Shut down the instance and restart it in MOUNT mode.d. Adjust initialization parameters: LOG_ARCHIVE_DEST_n

SQL> ALTER DATABASE RECOVER TO 2 LOGICAL STANDBY db_name;

Step 5: Convert to a Logical Standby DatabasePerform the following steps 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 logical standby database. 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. Create a new password file using the orapwd utility. You must create a new password file because the conversion process changes the database name for the logical standby database.

c. Shut down the logical standby database instance and restart it in MOUNT mode.d. 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 the the primary database

Modify the LOG_ARCHIVE_DEST_1 parameter to be valid for (ONLINE_LOGFILES,ALL_ROLES).

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 6: Open the Logical Standby Database

a. Open the new logical standby database with the RESETLOGS option:

b. Start the application of redo data to the logical standby database:

SQL> ALTER DATABASE OPEN RESETLOGS;

SQL> ALTER DATABASE START LOGICAL STANDBY 2 APPLY IMMEDIATE;

Step 6: Open the Logical Standby DatabasePerform the following steps to open the logical standby database and start SQL Apply:

a. On the logical standby database, issue the ALTER DATABASE OPEN RESETLOGScommand 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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 7: Verify That the Logical Standby Database Is Performing Properly

a. Verify that the archived redo log files were registered:

b. Begin sending redo data to the standby database:

c. Query the DBA_LOGSTDBY_LOG view to verify that the archived redo log files were registered.

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, 2 DICT_BEGIN, DICT_END3 FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;


Step 7: Verify That the Logical Standby Database Is Performing ProperlyAfter you create your logical standby database, set 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. Perform the following steps to verify that the logical standby database is functioning properly:

a. Connect to the logical standby database and query the DBA_LOGSTDBY_LOG view to verify that the archived redo log files were registered on the logical standby system:

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, 2 DICT_BEGIN,DICT_END3 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 re-query the DBA_LOGSTDBY_LOG view as

shown in step a. This enables you to verify that the new archived redo log files were registered.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 7: Verify That the Logical Standby Database Is Performing Properly

d. Verify that redo data is being applied correctly:

e. View the V$LOGSTDBY view to see current SQL Apply activity:

f. Check the overall progress of SQL Apply:

SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS 2 WHERE NAME = 'coordinator state';

SQL> SELECT TYPE, HIGH_SCN, STATUS 2 FROM V$LOGSTDBY;

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 data from the archived redo log files is not being applied to the logical standby database.

e. Query the V$LOGSTDBY view on the logical standby database to see a current snapshot of SQL Apply activity. A text message describing the current activity of each process that is involved in reading and applying changes is displayed.

f. Query the V$LOGSTDBY_PROGRESS view on the logical standby database to check the overall progress of SQL Apply:


Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Additional Configuration Tasks

Perform the following tasks as appropriate for your configuration:• Configure standby redo logs.• Enable Flashback Database.• Upgrade the data protection mode.

Additional Configuration TasksPerform the following tasks as appropriate for your logical standby database:

• Configure standby redo logs: Standby redo logs are required for standby databases running in maximum protection mode and maximum availability mode. However, configuring standby redo logs is recommended on all standby databases because, during a failover, Data Guard can recover and apply more redo data from standby redo log files than from the archived redo log files alone. The standby redo logs should exist on both primary and standby databases and have the same size and names.

• Enable Flashback Database: Flashback Database eliminates the need to re-create the primary database after a failover. Flashback Database is similar to conventional point-in-time recovery in its effects, enabling you to return a database to its state at a time in the recent past. Flashback Database is faster than point-in-time recovery because it does not require restoring data files from backup or the extensive application of redo data. You can enable Flashback Database on the primary database, the standby database, or both.

• Upgrade the data protection mode: The Data Guard configuration is initially set up in maximum performance mode (the default).

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to use SQL commands to create a logical standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Performing Switchover and Failover

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to do the following:• Explain the database roles• Perform a switchover• Perform a failover• Use Flashback Database after a failover

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Types of Roles in an Oracle Data Guard Configuration

There are two types of roles in an Oracle Data Guard configuration:• User role: identifies the group and determines the

privileges assigned to a user.• Database role: identifies what role (primary or standby)

the database plays in a Data Guard configuration.

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

Types of Roles in an Oracle Data Guard ConfigurationUser roles are named groups of related privileges that you grant to users or other user roles. User roles are designed to ease the administration of the end-user system and schema object privileges. Database roles identify what “part” the database is “playing” in the Data Guard configuration. A database can be in one of two roles:

• Primary• Standby

A database that is in the standby role is one of the following types:• Physical standby• Logical standby

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Role Management Services

• A database operates in one of two mutually exclusive roles in a Data Guard configuration:– Primary role: The database is operating in the primary

role, and redo transport services are shipping redo to the standby databases.

– Standby role: The database is operating in the standby role, and log apply services are applying the archived redo logs to the standby database.

• With role management services, you can change these roles dynamically.

Role Management ServicesYou 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Role Transitions: Switchover and Failover

• Not automatically invoked• Switchover

– Planned role reversal– Used for OS or hardware maintenance

• Failover– Unplanned role reversal– Used in an emergency– Minimal or no data loss depending on the

data-protection mode– Fast-start failover can be enabled for automatic failover

Role Transitions: Switchover and FailoverSwitchover and failover operations are not invoked automatically. You must initiate switchover or failover operations by using a SQL statement or by using the Data Guard GUI or Data Guard broker command-line interface (CLI).SwitchoverYou can use the switchover feature to switch the role of the primary database to one of the available standby databases. The chosen standby database becomes the primary database, and the original primary database then becomes a standby database. There is no need to re-create any of the databases in the switchover operation. There is no data divergence between the original and the new primary database after the successful completion of the database switchover.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Role Transitions: Switchover and Failover (continued)FailoverYou invoke a failover operation when a catastrophic failure occurs on the primary database, and there is no possibility of recovering the primary database in a timely manner. During a failover operation, the incapacitated primary database is removed from the Data Guard environment and a standby database assumes the primary database role. You invoke the failover operation on the standby database that you want to fail over to the primary role.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. Fast-start failover is discussed in detail in the lesson titled “Enabling Fast-Start Failover.”

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Choosing the Best Role Transition Operation

Are you performing a planned role transition so that you can perform hardware or software maintenance on the system that currently hosts the primary database?

Switch over to best available standby database.

Yes

Can you run crash recovery to repair the primary database in a timely manner?

Yes Repair primary database.

No

No

Fail over to best available standby database.

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Switchover

• Transitions the roles of the primary and standby databases

• No resetting of the online redo logs of the new primary database

• No data loss

SwitchoverA switchover operation transitions the primary database to the standby role and transitions the standby database to the primary role, without resetting the online redo logs of the new primary database. If the switchover operation involves a physical standby database, both the primary database and the physical standby database switching over to the primary role will be shut down and restarted. However, there is no need to shut down and restart any other standby databases that are not participants in the switchover operation. If the switchover operation involves a logical standby database, there is no need to shut down and restart either the primary database or any of the standby databases. Logical standby databases do not need to be shut down and restarted.Note: All extra RAC instances will be shut down and restarted.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Switchover: Before

Standbydatabase

Read/writetransactions

Primarydatabase

San FranciscoBoston

Oracle Net

Application

Application

Read-only reports

Switchover: BeforeFor example, assume that the primary database is located in San Francisco and the physical standby database is located in Boston. Switchovers are initiated only on the primary database. They cannot be initiated from the standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Switchover: After

Standbydatabase


Primarydatabase

Application

Application

Read-only reports

San FranciscoBoston

Oracle Net

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Standby Redo Logs and Switchovers

Standby redo logs should be configured on the primary database to ease switchovers.

Redo shipment

RFS

Standbyredo logs

Online redo logs

Primarydatabase

Standbydatabase

Standbyredo logs

Standby Redo Logs and SwitchoversStandby 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Preparing for a Switchover

Verify the following in preparation for the switchover operation: network connectivity between the primary and standby locations.

Preparing for a SwitchoverEach location in the Data Guard configuration should have connectivity through Oracle Net to the primary database and to all associated standby databases.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Switchover by UsingEnterprise Manager

Select the database and click Switchover.

Performing a Switchover with Enterprise ManagerThe following tasks are performed when Enterprise Manager is used for the switchover:

a. A check is made to ensure that the primary database and standby database are not currently in an error status condition and that broker management of the primary database is enabled and online.

b. Any active sessions connected to the primary database are automatically closed during the switchover.

c. The primary database is first changed to the standby role, and then the standby database is changed to the primary role.

d. If the switchover target is a physical standby database, the target and primary databases are each restarted.

To initiate a switchover by using Enterprise Manager:1. On the Data Guard page, select the standby database that you want to become the primary

database.2. Click Switchover.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Click Yes to confirm.

Performing a Switchover with Enterprise Manager (continued)3. The Data Guard Switchover Confirmation page appears.4. You can view active sessions by clicking the Browse Primary Database Sessions link.5. Click Yes to continue with the switchover, or click No to cancel.

You cannot cancel the switchover operation after it has begun.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Performing a Switchover with Enterprise Manager (continued)The Data Guard Switchover processing page displays the progress of the switchover operation as it performs the following steps:

• Switch roles between the primary and standby databases. If the switchover target is a physical standby database, it is restarted along with the primary database.

• Wait for the Data Guard broker to complete the initialization tasks required to switch the database roles.

You can view the database alert log of the primary and standby databases by clicking the respective “View alert log” links. A new browser window opens with the content of the alert log.After the switchover operation is complete, you are returned to the Data Guard page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Switchover to a Physical Standby by Using SQL

Perform these steps only if you are not using the Data Guard broker.On the original primary database:1. Verify that it is possible to perform a switchover

operation.2. Initiate the switchover operation on the primary

database:

3. Shut down and restart the instance.

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO 2 PHYSICAL STANDBY;

Performing a Switchover to a Physical Standby by Using SQLYou can perform a switchover using SQL, as described in the following steps. You should not execute these steps when managing your configuration with the Data Guard broker. Consider using the Data Guard broker to automate and simplify the switchover procedure.Execute steps 1 through 3 on the original primary database:

1. Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary database to verify that it is possible to perform a switchover operation. A TO STANDBY value in the SWITCHOVER_STATUS column indicates that it is possible to switch the primary database to the standby role.

2. To transition the primary database to a physical standby database role, execute the following SQL statement:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO2 PHYSICAL STANDBY WITH SESSION SHUTDOWN WAIT;

The WAIT option specifies that control is not returned to you until the statement completes.3. Shut down the instance and restart the database in MOUNT mode:

SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP MOUNT;

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Switchover to a Physical Standby by Using SQL

On the original physical standby database:1. Verify the switchover status in the V$DATABASE view.2. Switch the physical standby database role to the

primary role.3. If the standby database was opened read-only, shut

down and restart the new primary database. If it was not opened read-only, open the database.

4. Begin archiving logs to the physical standby database.

Performing a Switchover to a Physical Standby by Using SQL (continued)Execute steps 4 through 7 on the original standby database:

4. After you switch the primary database to the standby role and the switchover notification has been received by the standby database, you should verify that the switchover notification has been processed by the standby database by querying the SWITCHOVER_STATUS column of the V$DATABASE fixed view on the standby database. You should see a value of TO_PRIMARY.

5. Execute the following SQL statement on the physical standby database that you want to switch to the primary role: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY

6. If the standby database was opened read-only, shut down and restart the new primary database.

SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP;

If it was not opened read-only, open the database with the ALTER DATABASE OPENcommand.The selected physical standby database is now transitioned to the primary database role. There is no need to shut down and restart any other standby databases that were online at the time of the switchover operation.

7. Issue the following statement on the new primary database to start redo transport:SQL> ALTER SYSTEM SWITCH LOGFILE;

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Switchover to a Logical Standby by Using SQL

On the original primary database:1. Verify that it is possible to perform a switchover.2. Prepare the primary database for the switchover:

SQL> ALTER DATABASE PREPARE TO SWITCHOVER 2 TO LOGICAL STANDBY;

Performing a Switchover to a Logical Standby by Using SQLWhen you perform a switchover that changes roles between a primary database and a logical standby database, you must always initiate the switchover on the primary database and complete it on the logical standby database.Perform steps 1 and 2 on the original primary database:

1. Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary database to verify that it is possible to perform a switchover operation. A TO STANDBY or SESSIONS ACTIVE value in the SWITCHOVER_STATUS column indicates that it is possible to switch the primary database to the standby role.

2. Issue the following SQL statement to prepare the current primary database for a logical standby database role:

SQL> ALTER DATABASE PREPARE TO SWITCHOVER 2 TO LOGICAL STANDBY;

This statement notifies the current primary database that it will soon switch to the logical standby role and begin receiving redo data from a new primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




On the original logical standby database:3. Prepare the logical standby database for switchover:

SQL> ALTER DATABASE PREPARE TO SWITCHOVER 2 TO PRIMARY;

Performing a Switchover to a Logical Standby by Using SQL (continued)Perform step 3 on the logical standby database:

3. Issue the following statement to build a LogMiner dictionary on the logical standby database that is the target of the switchover:

SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;

This statement also starts redo transport services on the logical standby database to begin transmitting its redo data to the current primary database and to other standby databases in the Data Guard configuration. The sites receiving redo data from this logical standby database accept the redo data, but they do not apply it.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




On the original primary database:4. Verify the switchover status in V$DATABASE.5. Switch the primary database to the logical standby

database role:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER 2 TO LOGICAL STANDBY;

Performing a Switchover to a Logical Standby by Using SQL (continued)Perform steps 4 and 5 on the original primary database:

4. Verify that the LogMiner dictionary was received by the primary database by querying the SWITCHOVER_STATUS column of V$DATABASE on the primary database. When the query returns TO LOGICAL STANDBY in the SWITCHOVER_STATUS column, proceed with step 5.

5. Issue the following SQL statement to transition the primary database to a logical standby database role:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER 2 TO LOGICAL STANDBY;

This statement waits for all current transactions on the primary database to end and prevents any new users from starting new transactions. It also puts a marker in the redo data to provide a synchronization point for logical standby database operations.Executing this statement also prevents users from making any changes to the data being maintained in the logical standby database. To ensure faster execution, ensure that the primary database is in a quiet state with no update activity before issuing the switchover statement. You can query V$TRANSACTIONS for the status of any current in-progress transactions that could delay execution of this statement.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




SQL> ALTER DATABASE COMMIT TO SWITCHOVER 2 TO PRIMARY;


On the new primary database (original logical standby database):6. Verify the switchover status in V$DATABASE.7. Switch the logical standby database to the primary

database role.

8. Ensure that all standby databases begin receiving redo data.

Performing a Switchover to a Logical Standby by Using SQL (continued)Perform steps 6, 7, and 8 on the new primary database (original logical standby database):

6. Verify that the switchover notification was processed by the target standby database by querying the SWITCHOVER_STATUS column of the V$DATABASE fixed view on the target standby database. The SWITCHOVER_STATUS value is updated to show progress during the switchover. When the status is TO PRIMARY, proceed with step 7.

7. Issue the following SQL statement to switch the logical standby database to the primary role:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

8. Issue the following statement to perform a log switch and to ensure that all logical standby databases begin receiving redo data from the new primary database:


Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




On the new logical standby database:9. Start SQL Apply.

SQL> ALTER DATABASE 2 START LOGICAL STANDBY APPLY;

Performing a Switchover to a Logical Standby by Using SQL (continued)Perform step 9 on the new logical standby database:

9. Issue the following statement to start SQL Apply:SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Considerations When Performing a Switchover to a Logical Standby Database

• Switchover operation does not cause a shutdown of the primary.

• There is no need to terminate user sessions, but termination is recommended.

• Logical standby database may not have all data.

Considerations When Performing a Switchover to a Logical Standby DatabaseConsider the following when performing a switchover to a logical standby database:

• Unlike a switchover to a physical standby database, a switchover to a logical standby database does 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 completes and the database guard is turned on, you should terminate such open sessions now. The database guard prevents users from making changes in the logical standby database.

• If you switch over to a logical standby database, there may be a loss of data if the logical standby database contains only a subset of the data that is present in the primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Situations That Prevent a Switchover

You cannot perform a switchover in the following situations:• Archived redo log files are unavailable.• Point-in-time recovery is required.• Production database is not open and cannot be

opened.

Situations That Prevent a Switchover The following situations prevent the execution of a switchover operation:

• Archived redo log files are unavailable: If there is a gap in the archived redo log files on the standby database, you are not able to switch over to that standby database.

• Point-in-time recovery is required: When you perform a switchover to a standby database, you always switch over to the current state of the primary database. You cannot switch over to a time in the past.

• Production database is not open and cannot be opened: A switchover is initiated on the primary database while it is in the open state. If you cannot open the primary database, a switchover is not possible.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Failover

Standbydatabase becomes primary database.


Online redologs

Local archiving

San FranciscoBoston

Archived redologs

Application

Online RedoLogs

Local Archiving

Archived redologs

Primary database

FailoverYou invoke a failover operation when a catastrophic failure occurs on the primary database and there is no possibility of recovering the primary database in a timely manner. During a failover operation, the primary database is removed from the Data Guard environment and a standby database assumes the primary database role. Failing over to a standby database is a permanent operation. You cannot undo the failover and return the database to its former role as a standby database. Because of this, you should invoke a failover operation only in an emergency.It is not always necessary to fail over to the standby database. In some cases, recovery of the primary database may be faster. Most failures can be resolved at a primary database within a reasonable amount of time.In a failover operation:

• The original primary database is presumed to be lost. You must re-create (or flash back) the original primary database as a new standby database, if desired.

• Standby databases that are online at the time of the failover operation, but are not involved in the role transition, do not need to be shut down and restarted.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Failover Considerations

• Old primary database is no longer part of the configuration.

• Data loss is possible.• Failover should be used only in an emergency.• Special-case failover: activation of a standby

Failover ConsiderationsDuring 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 within a reasonable amount of time. The specific actions that are performed during a failover vary depending on whether a logical or physical standby database is involved in the failover operation, the state of the configuration at the time of the failover, and the specific SQL commands that are used to initiate the failover.There is also a special-case failover in which the standby database is activated. This should be avoided unless absolutely necessary because it causes all other databases in the configuration to become permanently disabled.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Failover by UsingEnterprise Manager

Select the database and click Failover.

Performing a Failover with Enterprise ManagerYou should perform a failover only in the event of a software or system failure that results in the loss of the primary database. The failed primary database is disabled by the broker and must be re-created. The standby database then assumes the primary database role.To initiate a failover by using Enterprise Manager:

1. On the Data Guard page, select the standby database that you want to become the primary database.

2. Click Failover.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Performing a Failover with Enterprise Manager (continued)3. Confirm that you want to proceed with the failover operation by clicking Yes.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Select the failover type and click Yes.

Performing a Failover with Enterprise Manager (continued)4. On the Data Guard Failover Confirmation page, you must specify the type of failover that

you want to perform:- Complete: All available redo is applied on the standby database. Oracle Corporation

recommends that you specify this type of failover.- Immediate: No additional data is applied on the standby database resulting in a data

loss failover and should be used only when a Complete failover is not possible.5. Select the failover option, and then click Yes to confirm the failover operation.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Performing a Failover with Enterprise Manager (continued)After you click Yes, the Failover Processing page shows you the progress of the failover operation. You cannot cancel this operation after it begins.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Failover to a Physical Standby Database

The physical standby database needs to be

reinstated.

Performing a Failover to a Physical Standby DatabaseDuring the failover operation, the selected standby database transitions into the primary role. If the failover target is a physical standby database, it is restarted. If you are failing over to a logical standby database, it is not restarted. When the operation is completed, the Data Guard Overview page reflects the updated configuration.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. 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 there must be sufficient flashback logs on that database for the reinstatement to succeed. In addition, the database to be reinstated and the new primary database must have network connectivity.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Failover 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 DatabaseWhen 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Failover to a Physical Standby Database by Using SQL

1. Identify and resolve any gaps in the archived redo log files.

2. Repeat step 1 until all gaps are resolved.3. Copy any other missing archived redo log files.4. Initiate the failover operation on the target standby

database.5. Convert the physical standby database to the primary

role.6. Complete the transition of the standby database to the

primary database role.7. (Optional) Back up the new primary database. 8. (Optional) Restore the failed primary database.

Performing a Failover to a Physical Standby Database by Using SQL Perform the following steps to fail over to a physical standby database by using SQL.Note: If the target standby database was operating in maximum protection mode, no gaps in the archived redo log files should exist, and you can proceed directly to step 4. Otherwise, begin with step 1 to determine if any manual gap resolution steps must be performed.

1. To determine if there are gaps in the archived redo log files on the target standby database, query the V$ARCHIVE_GAP view. This view contains the sequence numbers of the archived redo log files that are known to be missing for each thread. The data returned reflects the highest gap only.

SQL> SELECT thread#, low_sequence#, high_sequence# 2 FROM v$archive_gap;

If possible, copy all of the identified missing archived redo log files to the target standby database from the primary database and register them. Execute the following command to register the redo log files:

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';Perform this step for each thread.

2. Repeat step 1 until all gaps are resolved. The query that is executed in step 1 displays information for the highest gap only. Repeat step 1 until the query returns no rows.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Performing a Failover to a Physical Standby Database by Using SQL (continued)3. To determine if there are any other missing archived redo log files, query the V$ARCHIVED_LOG view on the target standby database to obtain the highest sequence number for each thread.

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#)2 OVER (PARTITION BY thread#) AS LAST 3 FROM V$ARCHIVED_LOG;

Copy to the target standby database any available primary database archived redo log files that contain sequence numbers higher than the highest sequence number that is available on the target standby database. Then register those redo log files by issuing the following SQL statement:

SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

Perform this step for each thread.After registering all available archived redo log files, query the V$ARCHIVE_GAP view (as described in step 1) to verify that no additional gaps were introduced in step 3.

4. Execute the following SQL statement to initiate the failover:SQL> ALTER DATABASE RECOVER

2 MANAGED STANDBY DATABASE FINISH FORCE;

5. Transition the physical standby database to the primary database role by issuing the following SQL statement:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

After issuing this SQL statement, you can no longer use this database as a standby database. Any subsequent redo that is received from the original primary database cannot be applied. During the failover process, the standby redo log files are automatically archived and recovered on all other standby databases that are derived from the original primary database if the standby destinations are correctly defined on the new primary database.

Perform step 6 on the new primary database.6. If the physical standby database has not been opened in read-only mode since the last time

it was started, open the new primary database as follows and proceed to step 7:SQL> ALTER DATABASE OPEN;

If the physical database has been opened in read-only mode since the last time it was started, shut down the target standby database (new primary database) and restart it as follows:

SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP;

7. Perform an open backup of the database after opening the database. Although performing a backup immediately is not required, it is recommended because you cannot recover changes that are made after the failover without a complete backup copy of the database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Performing a Failover to a Physical Standby Database by Using SQL (continued)8. After a failover, the original primary database no longer participates in the configuration.

After performing a failover, you may be able to optionally restore the failed primary database as a new standby database using either of the following methods:

- Use Flashback Database to restore the failed primary database to a point in time before the failover occurred, and then convert it into a standby database.

- Re-create the failed database and add it to the configuration as a new standby database. To reuse the old primary database in the new configuration, you must re-create it as a standby database using a backup copy of the new primary database.

After the failed primary database is restored and is operating in the standby role, you can optionally perform a switchover to transition the databases to their original (pre-failure) roles.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Failover to aLogical Standby Database by Using SQL

1. Copy missing redo logs to the logical standby database.

2. Register the missing redo logs:

3. If it exists, register the partially filled archive log file.4. Ensure that all redo log files have been applied to the

new primary database.

SQL> ALTER DATABASE REGISTER LOGICAL 2 LOGFILE 'filespec';


Performing a Failover to a Logical Standby Database by Using SQLTo perform failover for logical standby databases using SQL:

1. If redo logs exist on the primary database that have not yet been applied on the logical standby database, manually copy the redo logs to that standby database.

2. You must register the redo log files that you manually copied from the original primary database. Issue the following SQL statement for each missing redo log file on the logical standby:

SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 'filespec';

3. On the logical standby database, check if there is a partially written archived log file. If it exists, this file has a sequence number that is one greater than the last registered archived log file. If it exists, register the partially filled archived log file.

4. On the new primary database, ensure that the remaining redo logs have been applied by checking the V$LOGSTDBY_PROGRESS view. When the values in the APPLIED_SCNand LATEST_SCN columns are equal, all available redo has been applied. The logical standby database now contains as much data as possible from the primary database. Issue the following query:


Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Failover to aLogical Standby Database by Using SQL

5. Activate the new primary database:

6. Enable archiving of redo logs.7. Begin SQL Apply operations on all logical standby

databases:

SQL> ALTER DATABASE ACTIVATE 2 LOGICAL STANDBY DATABASE3 FINISH APPLY;

SQL> ALTER DATABASE START LOGICAL STANDBY 2 APPLY NEW PRIMARY dblink;

Performing a Failover to a Logical Standby Database by Using SQL (continued)5. To stop the RFS process, apply remaining redo, stop SQL Apply, and activate the database

in the primary database role, issue the following statements on the logical standby database that you are transitioning to the new primary role:

SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE2 FINISH APPLY;

6. Enable archiving of redo logs to all remote logical standby destinations, as in the following example:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE

In general, when the database operates in the primary role, you must enable archiving of redo logs to remote destinations. When the database operates in the standby role, you must disable archiving of redo logs to remote destinations.

7. Issue the following command to begin SQL Apply operations on all logical standby databases in the configuration:

SQL> ALTER DATABASE START LOGICAL STANDBY 2 APPLY NEW PRIMARY dblink;

Note: Any logical standby databases that are more current (have applied more redo operations) than the standby database to which the primary database has failed over to must be re-created from a backup of the new primary database and added back to the configuration.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Activating a Standby Database

When you are unable to fail over, you can activate a standby database by issuing one of the following commands (depending on the role of the database):

SQL> ALTER DATABASE ACTIVATE 2 LOGICAL STANDBY DATABASE;

SQL> ALTER DATABASE ACTIVATE 2 PHYSICAL STANDBY DATABASE;

Activating a Standby DatabaseYou can use the ALTER DATABASE ACTIVATE STANDBY DATABASE command to force the standby database into the primary role. Specify the appropriate option, PHYSICAL or LOGICAL, for the type of database that you are activating. You can issue this command in a situation in which you cannot perform a failover operation.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Restoring Databases After a Role Transition

Additional steps may be needed to restore your disaster-recovery solution after a role transition:• Databases may be disabled, but are not removed from

the broker configuration.• Reenable broker management of the databases:

– Reinstate databases using the REINSTATE DATABASEcommand or through Enterprise Manager.

– Re-create databases from a copy of the primary database and reenable the database.

Restoring Databases After a Role TransitionIf a database can be reinstated, it has the following status after a complete failover: ORA-16661: the standby database needs to be reinstated. The “Database must be reinstated” message is displayed in the Status column in Enterprise Manager. Reinstate the database using the DGMGRL REINSTATE DATABASE command or the reinstate option in Enterprise Manager.A database that must be re-created from a copy of the new primary database, has the following status: ORA-16795: the broker detects that database re-creation is required. Re-create the standby database from a copy of the primary database and then reenable it.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Flashback Through Standby DatabaseRole 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 will be 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 TransitionsYou can 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 timestamp 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, making a physical standby database more useful. Previously, you could open standby databases as read-only only. Read-only mode is usually not adequate for running report tools because these tools typically also change the database. In Oracle Database 10g Release 2, a physical standby database can be temporarily activated to run reports and tests. After noting or saving the results, you can flash back your database to revert to a standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Flashback Database After Failover

Failover

New standby database

Redo

RedoNew primary database

Flashback

Primary database

Standby database

Using Flashback Database After FailoverYou 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. You can use the Flashback Database feature to convert the old primary database into a new standby database without re-creating the database. You can flash back the old primary database so that it contains only those changes that are already applied to the old standby database. This enables you to convert the old primary database into a new standby database without restoring the old primary database.Note: You must have the Flashback Database feature enabled on the old primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Using Flashback Database After Failover (continued)Physical Standby ConfigurationIn a physical standby configuration, use the following procedure to avoid reinstantiating the old primary database after a failover:

1. On the new primary database, issue the following query to determine the system change number (SCN) at which the old standby database became the new primary database:

SELECT standby_became_primary_scn FROM v$database;

2. After the old primary database site is available, mount the old primary database.STARTUP MOUNT;

3. Flash back the old primary database to the “standby became primary” SCN that you determined in step 1:

FLASHBACK DATABASE TO SCN <SCN>;

4. On the old primary database, issue the following command to convert the control file to a standby control file:

ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

5. Shut down the old primary instance.SHUTDOWN IMMEDIATE;

6. Mount the old primary database. The old primary database is now your new standby database.

STARTUP MOUNT;

7. On the new primary database, enable redo transport to the old primary database (new standby database). Check the status of the archive destinations and enable any that are not enabled.

SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR, SRL FROM V$ARCHIVE_DEST_STATUS;ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;

Then, archive a new log to the new standby by issuing the following command:ALTER SYSTEM ARCHIVE LOG CURRENT;

8. On the new standby database, start managed standby recovery. The role reversal is now complete:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

If you are using real-time apply:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Using Flashback Database After Failover (continued)Logical Standby ConfigurationIn a logical standby configuration, use the following procedure to avoid reinstantiating the old primary database after a failover:

1. On the new primary database, issue the following query to determine the SCN to which you want to flash back the failed primary database:

SELECT applied_scn AS flashback_scn FROM v$logstdby_progress;

2. On the new primary database, issue the following query to determine if you need to copy any redo log files to the failed primary database so that Flashback Database reaches a consistent state:

SELECT NAME FROM DBA_LOGSDTBY_LOGWHERE NEXT_CHANGE# >

(SELECT VALUE FROM DBA_LOGSTDBY_PARAMETERSWHERE NAME = 'STANDBY_BECAME_PRIMARY_SCN')

AND FIRST_CHANGE <= (FLASHBACK_SCN from step 1);

3. Shutdown (if required) and mount the failed primary database.SHUTDOWN IMMEDIATE;STARTUP MOUNT;

4. Flash back the old primary database to the “standby became primary” SCN that you determined in step 1:

FLASHBACK DATABASE TO SCN <SCN>;

5. Enable the Data Guard guard to prevent the job queue from executing:ALTER DATABASE GUARD ALL;

6. Open the database with the RESETLOGS option: ALTER DATABASE OPEN RESETLOGS;

7. Create a database link to the new primary database:CREATE PUBLIC DATABASE LINK mylinkCONNECT TO system IDENTIFIED BY passwordUSING 'service_name_of_new_primary_database';

8. Start SQL Apply:ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY mylink;

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to:• Use the Data Guard GUI to perform switchover and

failover operations• Use SQL commands to perform switchover and failover

operations• Use Flashback Database after a failover

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




This practice covers the following topics:• Performing a switchover• Performing a failover

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Enabling Fast-Start Failover

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to:• 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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Fast-Start Failover: Overview

Primary database

Fast-start failover standby database

Observer

Fast-Start Failover: OverviewFast-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 OCI client-side component that runs on a separate computer and monitors theavailability of the primary database.Note: Fast-start failover is an Oracle Data Guard 10g Release 2 feature.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



When Will Fast-Start Failover Occur?

Primary database


ObserverLoss of connectivity >

fast-start failover threshold

When Will Fast-Start Failover Occur?Fast-start failover occurs when any of the following conditions occurs:

• 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

• Database health-check mechanism determines that the primary database data files are offline• 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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Installing the Observer

Observer

• The observer is a separate OCI client-side component that monitors the availability of the primary database.

• Install it on a different computer from the primary and standby databases.

• Manage the observer through Oracle Enterprise Manager or by using DGMGRL commands.

Installing the ObserverTo use fast-start failover, you must install DGMGRL and run the observer software on a computer system that is separate from the primary and standby systems.To install DGMGRL on the observer computer, use one of the methods described as follows:

• 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 using DGMGRL commands but not Oracle Enterprise Manager.

• Install the full Oracle Database 10g software kit. This installation includes DGMGRL and the Oracle Enterprise Manager agent, allowing you to manage the observer using Oracle Enterprise Manager or DGMGRL commands.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Configuring Fast-Start Failover

1. Specify the target standby database.2. Set the FastStartFailoverThreshold property.3. Enable fast-start failover.4. Start the observer.5. Verify the configuration.

Configuring Fast-Start FailoverThe 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 1: Specifying the Target Standby Database


Primary database

EDRSR10P1_ORCL EDRSR10P1_SITE1

EDIT DATABASE edrsr10p1_orclSET PROPERTY FastStartFailoverTarget = edrsr10p1_site1;

Step 1: Specifying the Target Standby DatabaseIn a Data Guard configuration with multiple standby databases, you must set theFastStartFailoverTarget database property before enabling fast-start failover.Before enabling fast-start failover, set the FastStartFailoverTarget property for the primary database to the fast-start failover target standby database. When you enable fast-start failover, the Data Guard broker automatically sets the FastStartFailoverTarget property for the fast-start failover target standby database to the database name of the primary database.Execute the command when connected to the primary database or to any standby database with connectivity to the primary database within the configuration.The command syntax is as follows:

EDIT DATABASE database-nameSET PROPERTY FastStartFailoverTarget = FSFO-database-name;

Note: Database-name and FSFO-database-name are the values of the DB_UNIQUE_NAMEinitialization parameter for the respective databases.You do not need to set the FastStartFailoverTarget property in a configuration with only one standby database because the Data Guard broker will automatically set it appropriately for the primary database and the standby database when fast-start failover is enabled.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 2: Setting the Fast-Start Failover Threshold

EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = threshold-val;

Primary database

EDRSR10P1_ORCL

Step 2: Setting the Fast-Start Failover ThresholdThe fast-start failover threshold (FSFT) 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, non-zero number of seconds. The default value for FSFT is 30 seconds. When choosing a value for this parameter, 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 downtime during a critical outage.Recommended settings for the Fast-Start Failover Threshold are:

• 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 within the Data Guard broker configuration with connectivity to the primary database.Note: You can modify this property regardless of whether fast-start failover is enabled or disabled.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 3: Enabling Fast-Start Failover

ENABLE FAST_START FAILOVER;

Primary database


EDRSR10P1_ORCL EDRSR10P1_SITE1

Step 3: Enabling Fast-Start FailoverYou can use the Data Guard Manager command-line interface (CLI)—DGMGRL—to enable fast-start failover. When you issue the ENABLE FAST_START FAILOVER command, the observer is able to observe the primary database and the standby database, and initiate a fast-start failover when necessary. In addition to enabling fast-start failover, you must start the observer as described later in this lesson.The following prerequisites must be met to enable fast-start failover:

• At least one enabled standby database with standby redo log files must exit. The log files being shipped to it must have the LGWR, SYNC, and AFFIRM attributes. The redo transport mode property—LogXptMode—must be set to SYNC.

• The primary database must be configured with standby redo log files. Its LogXptModeproperty must be set to SYNC. This setting enables automatic reinstatement of the original primary database as a standby database in the event of a failover.

• The Data Guard broker configuration must be enabled and operating in maximum availability mode.

• Flashback Database must be enabled on the primary database and target standby database.• The primary database and target standby database must have connectivity.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 4: Starting the Observer

START OBSERVER [FILE=filename];

Observer

Primary database


Step 4: Starting the ObserverExecute the START OBSERVER command to start the observer. The START OBSERVER command directs DGMGRL to begin “observing” the Data Guard configuration to which DGMGRL is connected. You must execute this command on the computer where the observer is to reside.When you execute the START OBSERVER command, the observer retrieves the primary database and the fast-start failover target standby database connect descriptors and begins observation. It provides the name of its host computer to the Data Guard broker. This information is recorded in theObserverInfo configuration-level property and is displayed when you execute the SHOWCONFIGURATION VERBOSE command.The primary database must be available for the START OBSERVER command to succeed. The observer must be connected either to the primary database in the Data Guard configuration or to a standby database that has connectivity to the primary database.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 will receive an error message.If you disable fast-start failover while the observer is observing the configuration, then the observer idles waiting for fast-start failover to become enabled.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Step 4: Starting 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 STARTOBSERVER command to specify an explicit directory path and name for the configuration file on the observer computer as follows:

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; thus, 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, then the observer’s DGMGRL process will terminate.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Step 5: Verifying the Configuration

DGMGRL> SHOW CONFIGURATION VERBOSE;ConfigurationName: EDRSR8P1_ORCL.oracle.comEnabled: YESProtection Mode: MaxAvailabilityFast-Start Failover: ENABLEDDatabases:EDRSR8P1_ORCL - Primary databaseEDRSR8P1_SITE1 - Physical standby database

- Fast-Start Failover targetEDRSR8P1_SITE2 - Logical standby database

Fast-Start FailoverThreshold: 30 secondsObserver: EDRSR10P1

Current status for "EDRSR8P1_ORCL.oracle.com":SUCCESS

Step 5: Verifying the ConfigurationUse the SHOW CONFIGURATION VERBOSE command to review information about the fast-start failover configuration.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Viewing 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------------ -------------- --------- --------SYNCHRONIZED EDRSR8P1_SITE1 30 YES

OBS_HOST---------EDRSR10P1

Viewing InformationV$DATABASE contains the following columns providing detailed information about fast-start failover:• 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 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. Refer to the Data Guard broker drc* log files for additional information.

- REINSTATE IN PROGRESS: Reinstatement of the failed primary database as a new standby database is in progress.

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Viewing Information (continued)- STALLED: This status appears on the primary database if it simultaneously loses

connection to both the target standby database and the observer while synchronized.- SUSPENDED: This status appears on the target standby database when either the primary

database or the target standby database was shut down in a controlled fashion.- SYNCHRONIZED: The primary database and the fast-start failover target standby database

are synchronized with respect to redo.- UNSYNCHRONIZED: The target standby database does not have all the redo from the

primary database. 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 that the observer will attempt 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 is hosting the observer process

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Prohibited Operations After EnablingFast-Start Failover

Maximumprotection

Maximumperformance

Disable or deletethe fast-start failover

standby database

EDIT DATABASE SET PROPERTY LogXptModeEDIT DATABASE SET PROPERTY FastStartFailoverTarget

Prohibited Operations After Enabling Fast-Start FailoverAfter you have enabled fast-start failover, you cannot perform any of the following operations that would undermine the fast-start failover environment:

• Change the configuration protection mode to either maximum protection or maximum performance.

• Change the LogXptMode property for the primary or target standby databases.• 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Disabling Fast-Start Failover

Primary database


Observer

DISABLE FAST_START FAILOVER [FORCE];

Disabling Fast-Start FailoverYou can use the Data Guard CLI to disable fast-start failover. The primary database and the fast-start failover target standby database must have connectivity unless you use the FORCE option.When you issue 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, then 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, then the Data Guard broker will disable fast-start failover locally. The Data Guard broker then records this change persistently in the Data Guard broker metadata and propagates this change to all databases in the Data Guard broker configuration to which the primary database has connectivity.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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, then fast-start failover will be disabled only on that target standby database. If the target standby database regains connectivity with the primary database, then the primary database will disable 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, then it is ignored by the primary database. Fast-start failover will be 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 a bystander standby database that has connectivity with the primary database, or to the fast-start failover target standby database itself, if fast-start failover is to be persistently disabled.Note: Disabling fast-start failover does not stop the observer. Stopping the observer is discussed later in the lesson.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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 OptionYou should use the FORCE option in the following situations:

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Stopping the Observer

Primary database


Observer

STOP OBSERVER;

Stopping the ObserverIf you no longer want to use fast-start failover or 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 regardless of whether 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, then 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 STOPOBSERVER command, the Data Guard broker can accept a new observer regardless of whether the stopped observer is terminated.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing Role Changes

Primary database


FailoverSwitchover

Performing Role ChangesYou can perform role changes in a fast-start failover configuration as long as the role change is directed to the fast-start failover target standby database and the configuration is synchronized. The following are some of the restrictions that apply:

• Switchover to the fast-start failover target standby database: This is allowed as long as the configuration is synchronized. No switchovers are permitted to the fast-start failover target standby database if the configuration is unsynchronized. Switchovers to non-fast-start failover targets are not permitted.

• A manual failover to the fast-start failover target standby database: This is permitted as long as the target standby database is synchronized. You can perform manual failover if the fast-start failover configuration is suspended. If the manual failover fails, the Data Guard broker will ensure that fast-start failover is suspended to prevent the observer from performing a fast-start failover operation. You can correct the problem and retry the manual failover operation.

• Fast-Start Failover: Fast-start failover to a synchronized target standby database can occur at any time after the observer and the target standby database lose connectivity with the primary database. If the failover fails, the Data Guard broker disables fast-start failover. In addition, the observer, upon receiving an error status from the attempted fast-start failover, will delete its metadata state and terminate. The observer is prevented from retrying a fast-start failover and repeatedly failing. You can correct the problem and attempt a manual failover.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Performing a Manual Failover

Primary database


Failover EDRSR10P1_SITE1EDRSR10P1_ORCL

FAILOVER TO edrsr10p1_site1;

Performing a Manual FailoverYou can perform a manual failover to the fast-start failover target standby database when fast-start failover is suspended because the primary database has been shut down. The FAILOVER command succeeds if the fast-start failover configuration is synchronized. The manual failover preserves the fast-start failover environment and the Data Guard configuration remains in maximum availability mode. The observer automatically reinstates the original primary database when it is restarted.Note: You cannot perform a manual failover if the fast-start failover target standby database is not synchronized with the primary database.If you must fail over to an unsynchronized fast-start failover target standby database or a bystander standby database, and then you must first disable fast-start failover for that standby database by executing the DISABLE FAST_START FAILOVER FORCE command. After you disable fast-start failover and perform the failover, fast-start failover is disabled for the entire configuration and the protection mode is changed to maximum performance.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Automatic Reinstatement AfterFast-Start Failover


Primary database

EDRSR10P1_SITE1EDRSR10P1_ORCL

Automatic Reinstatement After Fast-Start FailoverReinstatement 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. You cannot perform a subsequent fast-start failover until the original primary database is reinstated without reconfiguring the fast-start failover environment. Automatic reinstatement of the original primary database is triggered when all the following conditions are met:

• 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 in the fast-start failover configuration 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.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Automatic Reinstatement After Fast-Start Failover (continued)If these conditions are not met, automatic reinstatement of the original primary database will not take place and appropriate errors will be logged. You can then request manual reinstatement of the original primary database using the CLI or Enterprise Manager.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Manually Reinstating the Database


Primary database

EDRSR10P1_SITE1EDRSR10P1_ORCL

REINSTATE DATABASE edrsr10p1_orcl;

Manually Reinstating the DatabaseUse the REINSTATE DATABASE database-name command to reinstate the database. If the conditions for reinstatement are not satisfied, then 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, then 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 should the new primary database fail.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 database-name command does not require fast-start failover to be enabled. It can be used to reinstate an original primary database after a conventional no-data-loss failover.This command is not needed when fast-start failover is enabled and the database to be reinstated is the original primary database. In that case, the observer will automatically reinstate the database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Enterprise Manager toEnable Fast-Start Failover

Click Disabled to invoke the fast-start failover wizard.

Using Enterprise Manager to Enable Fast-Start FailoverOn the Data Guard page, click the Disabled link next to Fast-Start Failover to invoke the fast-start failover wizard to enable fast-start failover.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Select the database.

Click Set Observer.

Using Enterprise Manager to Enable Fast-Start Failover (continued)Select the fast-start failover target database and, optionally, the observer host. If the observer has not been started, click the Set Observer button.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Using Enterprise Manager to Enable Fast-Start Failover (continued)Specify the Observer host and Observer Oracle Home to indicate where the observer will be started.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Using Enterprise Manager to Enable Fast-Start Failover (continued)Flashback logging must be enabled on the primary database and the standby database to enable fast-start failover. If the primary database or the standby database does not have flashback logging enabled, the Enable Flashback Logging page displays. Specify the flash recovery area location, flash recovery area size, and flashback retention time for each database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Using Enterprise Manager to Enable Fast-Start Failover (continued)On the Confirmation: Enable Fast-Start Failover page, confirm that you want to enable fast-start failover to the named database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




Using Enterprise Manager to Enable Fast-Start Failover (continued)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 steps 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 is restarted, if required. • Fast-start failover is enabled.• The observer process is started.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Changing the Protection Modeand Disabling Fast-Start Failover

Changing the Protection Mode and Disabling Fast-Start FailoverIf you change the protection mode to a mode that does not support fast-start failover, then you implicitly disable fast-start failover.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Enterprise Manager toDisable Fast-Start Failover

Click the Enabled link to access the Change Mode

page.

Using Enterprise Manager to Disable Fast-Start FailoverAccess the Fast-Start Failover: Change Mode page by clicking the Fast-Start Failover link. Selecting Disable and the Stop observer option on the Fast-Start Failover: Change Mode page to disable fast-start failover.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Enterprise Manager toSuspend Fast-Start Failover

Using Enterprise Manager to Suspend Fast-Start FailoverSuspend fast-start failover by selecting Disable on the Fast-Start Failover: Change Mode page. Do not select the “Stop observer” option.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to:• 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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




This practice covers the following topics:• Enabling fast-start failover• 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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Using Data Guard in a Real Application Clusters Configuration

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to deploy Data Guard in a Real Application Clusters environment.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Real Application Clusters and Data Guard

Possible combinations of instances in the primary and standby databases:

YesYesMulti-Instance

YesYesSingle-Instance

Multi-InstanceStandby Database

Single-InstanceStandby Database

PrimaryInstance

Real Application Clusters and Data GuardYou can configure your Real Application Clusters (RAC) environment to switch over to another RAC environment or a single-instance environment. If you configure switchover to another RAC environment, the broker ships all redo from all primary database RAC instances to the single standby instance where apply services is running. After switchover or failover, your application is in a RAC, which should give the same performance as the previous configuration.Switchover and failover to a smaller system do not allow your application to perform as in the original configuration. If you are sending redo to a single-instance standby database, be sure to configure the number of standby redo logs on the standby database to be equal to the total number of online redo logs in all the instances of the RAC system.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Configuration Considerations with RAC

• Format for archived redo log file names: Thread variable (%t or %T) of LOG_ARCHIVE_FORMAT is mandatory.

• Data protection modes: Maximum protection or maximum availability mode; all instances could stop shipping redo.

Configuration Considerations with RACFormat for archived redo log file names: The thread variable (%t or %T) in the LOG_ARCHIVE_FORMAT parameter is mandatory for Real Application Clusters to uniquely identify the archived redo log files.Data protection modes: In a RAC configuration that is configured for maximum protection or maximum availability mode, any instance that loses connectivity with a standby destination causes all other instances to create a sync point for that destination. This action maintains the data integrity of the data that has been transmitted to that destination and can be recovered. When the failed standby destination comes back up, Data Guard runs the site in resynchronization mode until no gaps remain. Then, the standby destination can participate in the Data Guard configuration again.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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

Primary database Standby database

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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


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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Redo Transport with RAC to RAC

Primary instance A

Primary instance B

Standby instance C

Standby recovery instance D

Archived logs

Archived logs

Onlineredofiles

Standbyredofiles

Archivedlogs

LGWR RFS ARCn

LGWR

Primary database


MRP

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting Up a Primary Database with RAC

Primary instance A

Primary instance B

Archived logs

Archived logs

Onlineredofiles

LGWR

LGWR

Primary database

Setting Up a Primary Database with RACTo configure redo transport services on the primary database:

1. On all instances, define the LGWR attribute for the LOG_ARCHIVE_DEST_n parameter to specify that the LGWR process performs the archival operation.

2. Configure each primary instance to send its redo to the standby recovery instance by setting the LOG_ARCHIVE_DEST_n parameter to an appropriate value.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Setting Up a Standby Database with RAC

Standby instance C

Standby recovery instance D

Standbyredofiles

Archivedlogs

RFS ARCn


MRP

Setting Up a Standby Database with RACTo configure redo transport services on the standby database:

1. Create the standby redo log files. In a Real Application Clusters environment, the standby redo log files must reside on disk devices that are shared by all instances.

2. On the recovery instance, define the LOCATION attribute of the LOG_ARCHIVE_DEST_1initialization parameter to archive locally.

3. Start log apply services on the recovery instance.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Assigning Threads to Standby Redo Log Groups

SQL> ALTER DATABASE ADD STANDBY LOGFILE2 THREAD 1 'STBY_LOGFILE_1.SRL' SIZE 50M;

Primarydatabase

Standbydatabase

Standby redo logs

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Apply Instance Failover

• If the apply instance fails, transport of redo is also halted by default.

• Broker configuration:– Set ApplyInstanceTimeout to avoid downtime.

— Default is 120 seconds.— Set to 0 (zero) to disable.

– Optionally set PreferredApplyInstance.• Non-broker configuration: Set up a list of destination

connect identifiers.

Apply Instance FailoverWhen the apply instance fails, not only does log apply services stop applying log files to the standby database, but redo transport services stop transmitting redo data to the standby database. To tolerate a failure of the apply instance, the broker leverages the availability of the RAC standby database by automatically failing over log apply services to a different standby instance. To set up apply instance failover in a Data Guard broker–controlled configuration, set the ApplyInstanceTimeout property to specify the time period that the broker should waitafter detecting an apply instance failure and before initiating an apply instance failover. To select an appropriate timeout value, you must consider:

• If there is another mechanism in the cluster that will try to recover the failed apply instance• How long the primary database can tolerate not transmitting redo data to the standby

database• The overhead that is associated with moving the log apply services to a different instance.

The overhead may include retransmitting (from the primary database) all unapplied log files that have accumulated on the failed apply instance if those log files are not saved in a shared file system that can be accessed from other standby instances.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Apply Instance Failover (continued)You can also set the PreferredApplyInstance property of Data Guard broker to indicate which instance should take over this task if the current apply instance fails. If PreferredApplyInstance is not set, the broker picks a random instance that is currently running to be the new apply instance. If the Data Guard broker is not enabled for your configuration, Oracle’s high-availability best practices recommend setting up a list of destination connect identifiers in the tnsnames.orafile on the primary database, as in the following example:

CHICAGO=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=chicago_n1-server)(PORT=1521))(ADDRESS=(PROTOCOL=tcp)(HOST=chicago_n2-server)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CHICAGO)))

In this case, LGWR chooses the next entry in the list to send redo data to, after a timeout period that is specified in the NET_TIMEOUT attribute of the log_archive_dest_n parameter (if NET_TIMEOUT is not specified, it waits until the system’s TCP/IP timeout). However, the apply process (Redo Apply or SQL Apply) would need to be manually started in the new instance with SQL*Plus.The primary instance of the standby cluster will be brought down to ensure no data loss if all of the following are true:

• A connection list is not specified• The Data Guard broker is not enabled for the configuration• The apply instance for the last standby database fails• The LGWR process times out

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Role Transitions with RAC

• Switchovers: Only one primary instance and one standby instance can be active during a switchover.

• Failovers: Before performing a failover to a RAC standby database, shut down all but one standby instance.

Role Transitions with RAC Switchovers: For a RAC database, only one primary instance and one standby instance can be active during a switchover. Before a switchover, shut down all but one primary instance and one standby instance. After the switchover completes, restart the primary and standby instances that you shut down during the switchover.Failovers: Before performing a failover to a RAC standby database, shut down all but one standby instance. After the failover completes, restart the instances that were shut down.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Troubleshooting

• Switchover failure • Avoiding downtime during a network outage

TroubleshootingSwitchover failure: When your database is using RAC, active instances prevent a switchover from being performed. When other instances are active, an attempt to switch over fails and the following error message appears:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY *ORA-01105: mount is incompatible with mounts by other instances

Query the V$ACTIVE_INSTANCES view to determine which instances are causing the problem:

SQL> SELECT * FROM v$active_instances;

INST_NUMBER INST_NAME----------- ------------------------------

1 nleduc1.nl.oracle.com:orcl1

Connect to this instance and shut it down.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Troubleshooting (continued)Avoiding downtime: If you configured Data Guard to support a primary database in a RAC environment and the primary database is running in maximum protection mode, a network outage between the primary database and all of its standby databases will disable the primary database until the network connection is restored. The maximum protection mode dictates that if the last participating standby database becomes unavailable, processing halts on the primary database.If you expect the network to be down for an extended period of time, consider changing the primary database to operate in either maximum availability or maximum performance mode until network connectivity is restored. If you change the primary database to maximum availability mode, it is possible for there to be a lag between the primary and standby databases, but you gain the ability to use the primary database until the network problem is resolved.If you choose to change the primary database to maximum availability mode, it is important to use the following procedures to prevent damage to your data.The following steps describe what to do if the network goes down and you want to change the protection mode for the RAC configuration. The example assumes that you are using a server parameter file (SPFILE) rather than a text initialization parameter file (PFILE).

1. At this point, all RAC primary instances are shut down. Issue the STARTUP MOUNTcommand to start one instance:STARTUP MOUNT;

2. Change the mode from maximum protection to either maximum availability or maximum performance. For example, the following statement sets the maximum availability protection mode:

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

3. Open the RAC primary database for general access. When the network comes back up later, perform the following steps to revert to maximum protection mode:

1. Shut down all instances of the RAC primary database.2. Mount a single instance of the RAC primary database without opening it for general access.3. Change the mode on the RAC primary database from its current mode (maximum

availability or maximum performance) to maximum protection mode.4. Open the RAC primary database for general access.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to deploy Data Guard in a Real Application Clusters environment.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Other Considerations for Oracle Data Guard

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to do the following:• Back up the primary database with a physical standby

database • Back up a logical standby database • Use Flashback Database features in a Data Guard

configuration • Encrypt redo information • Configure cascaded redo log destinations

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using RMAN to Back Up a Physical Standby Database

1. Invoke RMAN.2. Allocate channels if needed.3. Issue the BACKUP command.4. Use the LIST command to verify the backup.

Using RMAN to Back Up a Physical Standby DatabaseUse the RMAN BACKUP command to back up the standby database. Performing a backup on the standby database is exactly the same as a backup of the primary database, except that the backup takes place on the standby site.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Restrictions and Usage Notes

• The database you are backing up must be a physical standby database.

• You must be connected to the recovery catalog when backing up.

• You cannot back up the standby control file.• You must connect to the physical standby database

with the TARGET keyword.

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Backup and Recovery of aLogical 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:– Can recover like any other database for loss of individual

files– Need to re-create if you lose entire database– Must use a binary copy of control file for control-file

recovery

Backup and Recovery of a Logical Standby DatabaseYou can back up your logical standby database by using the same method that you use for your primary database. The backup files are not interchangeable with the primary database. Remember that this is a different database.You can use the same recovery techniques as with any other database for loss of data files or online log files. You must use the backups of the logical (not the primary) database. If the entire logical standby database is lost, you must re-create the logical standby. If you lose all copies of your control file, you must use a binary copy of the control file when performing the recovery. Using a trace file or the CREATE CONTROLFILE command for control file recovery does not create a logical standby control file. You can make a binary copy of the control file by doing either of the following:

• Shut down the logical standby and copy the control file to a backup. • Issue the following command while the logical standby database is open:

ALTER DATABASE BACKUP CONTROLFILE TO '<filename>';

This command creates a binary copy of the control file with the name that you supply.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Flashback Across Database Changes

Flashback Database restores the database to a point-in-time before the following global database changes:• Database RESETLOGS operation• Database switchover or failover to a physical or logical

standby database• Physical standby database activation

Flashback Across Database ChangesIn Oracle Database 10g Release 2, you can use flashback database functionality to flash back through the global database changes described above. To flash back through any of these database state changes, Flashback Database must be previously enabled. Enabling Flashback Database for your database remains unchanged from the previous release. Previously, when any of these global database changes were made, the flashback logs were discarded. Oracle Database 10g Release 2 maintains the flashback logs through the above globaldatabase changes, thereby extending the functionality of the Flashback Database command.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Flashback Database and Real-Time Apply

RFS

Standbyredo log

MRP

ARC0

Archivedredo logs

Primary database

Standby database

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Using Flashback Database After RESETLOGS

Redo

Redo

Flashback

Primary database

Standby database

RESETLOGSafter

point-in-timerecovery


Using Flashback Database After RESETLOGSPhysical Standby ConfigurationFor 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 is far enough behind the primary database’s SCN, then the Redo Apply service will be able to interpret the OPEN RESETLOGS command without stopping.Use the following procedure to avoid re-creating a standby database after you have performed an OPEN RESETLOGS on the primary database and the managed recovery process has halted on the physical standby database:

1. On the primary database, determine an SCN that is at least two SCNs prior to the SCN when the OPEN RESETLOGS command was issued. This is necessary to enable the standby to recover properly through the OPEN RESETLOGS. Use the following query to find the “before RESETLOGS” SCN:

SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database;

2. On the standby database, obtain the current SCN by using the following query: SELECT TO_CHAR(current_scn) FROM v$database;

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Using Flashback Database After RESETLOGS (continued)3. Flash back the standby database to the “before RESETLOGS” SCN that you queried in

step 1: FLASHBACK STANDBY DATABASE TO SCN <before RESETLOGS SCN>;

4. Restart managed recovery on the standby database. The standby database should now be ready to receive and apply logs from the primary database:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Logical Standby ConfigurationFor a logical standby database, it is possible that the SQL Apply service might not halt when it encounters the OPEN RESETLOGS command in the redo information. If the logical standby database’s SCN is far enough behind the primary database’s SCN, then the SQL Apply service will be able to interpret the OPEN RESETLOGS command without stopping.Use the following procedure to avoid re-creating a standby database after you have performed an OPEN RESETLOGS on the primary database and the SQL Apply process has halted on the logical standby database:

1. On the primary database, determine an SCN that is at least two SCNs prior to the SCN when the OPEN RESETLOGS command was issued. This is necessary to enable the standby to recover properly through the OPEN RESETLOGS. Use the following query to find the “before RESETLOGS” SCN:

SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database;

2. On the standby database, obtain the current SCN with the following query: SELECT TO_CHAR(current_scn) FROM v$database;

3. Flash back the standby database to the “before RESETLOGS” SCN that you queried instep 1:

FLASHBACK STANDBY DATABASE TO SCN <before RESETLOGS SCN>;

4. Restart SQL Apply on the standby database. The standby database should now be ready to receive and apply logs from the primary database:

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Enabling Redo Encryption

Primarydatabase

Standbydatabase

Redo information encrypted

Enabling Redo EncryptionYou can optionally enable encryption of the redo data by using the following procedure:

1. Install the Oracle Advanced Security option at both the primary and standby databases.2. Configure the appropriate SQLNET.ORA parameters to enable Oracle Net to encrypt the redo

traffic shipped to the standby. An outline of the tasks to configure encryption on the client and on the server using Oracle Net Manager is as follows:

a. Navigate to the Oracle Advanced Security profile.b. Choose the Encryption tab.c. Select CLIENT or SERVER from the list.d. From the Encryption Type list, select one of the following: REQUESTED, REQUIRED,

ACCEPTED, or REJECTED. e. (Optional) In the Encryption Seed field, enter between 10 and 70 random characters; the

encryption seed for the client should not be the same as that for the server.f. Choose File > Save Network Configuration. The SQLNET.ORA file is updated.g. Repeat this procedure to configure encryption on the other system.

Refer to the Oracle Database Advanced Security Administrator’s Guide for detailed information.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Activating a Physical Standby Database for Reporting

Physical standby database

Flashback

Redoapply

Redo stream

Redotransport

Guaranteedrestorepoint

Primary database

Activate for

reporting

Activating a Physical Standby Database for ReportingIn Oracle Database 10g Release 2, using a combination of the capabilities of Data Guard, guaranteed restore points, and the Flashback Database features, a physical standby database can be temporarily activated in read/write mode for running reports and flashed back to revert it to a physical standby database. When the physical standby database is flashed back, Data Guard automatically synchronizes it with the primary database. You do not need to re-create the physical standby database from a backup copy of the primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




1. On the physical standby database, perform the following steps:a. Specify initialization parameters to define the flash

recovery area if not already configured.b. Cancel Redo Apply.c. Create a guaranteed restore point.

2. On the primary database, perform the following steps to ensure that the physical standby database can be reverted to the restore point:a. Archive the current log.b. Defer the log archive destination for the physical standby

database.

Activating a Physical Standby Database for Reporting (continued)The steps to activate a physical standby database for reporting are outlined on this page and the next.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y




3. Activate the physical standby database and set protection mode to maximum performance.

4. Perform reporting or testing on the activated database.5. Revert the activated database to a physical standby

database:a. Flash back to the restore point.b. Convert it back into a physical standby database.

6. On the primary database, reenable archiving to the physical standby database destination.

7. Allow Data Guard to automatically resynchronize the physical standby database or use RMAN incremental backups from the primary database to resynchronize the physical standby database.

Activating a Physical Standby Database for Reporting (continued)When you activate a physical standby database temporarily as read/write, it does not receive logs from the primary database to provide disaster protection. In this case, you should use multiple standby databases to ensure full disaster protection while a standby is activated temporarily. Also, you should note that any results stored in the database by a reporting tool are lost when the standby database is flashed back. Any results that should be saved must be copied from the database before flashing it back.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Cascaded Redo Log Destinations

Primarydatabase Standby

database

Standbydatabase

Redo

Redo

Cascading Redo Log DestinationsTo reduce the load on your primary system, you can implement cascaded redo log destinations, whereby a standby database receives its redo data from another standby database instead of directly from the primary database. You can configure a physical standby database to retransmit the incoming redo data that it receives from the primary database to other remote destinations in the same manner as the primary database.Note: You must use SQL commands when managing a cascaded redo log destination configuration because Data Guard broker does not support this feature.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Configuring Cascaded Redo Log Destinations: Physical Standby

• On the primary database, use the LGWR transport.• On the receiving standby database:

– Configure standby redo logs.– Configure LOG_ARCHIVE_DEST_n to send redo to the next

standby.

Physicalstandby

Primarydatabase

Physical orlogical standby

Configuring Cascaded Redo Log Destinations: Physical StandbyTo enable a physical standby database to send the incoming redo data to another set of destinations, you must do the following:

• Define the LOG_ARCHIVE_DEST_n initialization parameter on the primary database to set up a physical standby database as the starting point for a cascade to use the LGWR transport method. Use either the SYNC or the ASYNC network protocol, depending on your requirements.

• On the receiving physical standby database, define sufficient standby redo log files and ensure that archiving is enabled.

• Define the LOG_ARCHIVE_DEST_n initialization parameter on the physical standby database that will define the end points of the cascade.

Remember that, as part of the original setup of the physical standby database, you should have defined a local archive destination to be used for local archiving when the physical standby database transitions to the primary role. For example, you might define the LOG_ARCHIVE_DEST_1 initialization parameter to be the 'LOCATION=/physical1/arch' location. When the physical standby database switches roles, any archived redo log files are put into that directory with the same format that you defined with the LOG_ARCHIVE_FORMAT initialization parameter.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Role Transitions withCascaded Redo Log Destinations

• Standby databases that receive redo data from a physical standby database:– No change: Switchover and failover are exactly the same.– May take longer

• Standby databases that receive redo data from a logical standby database cannot participate in a switchover involving the primary database.

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

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned how to:• Back up the primary database with a physical standby

database • Back up a logical standby database • Use Flashback Database features in a Data Guard

configuration • Encrypt redo information • Configure cascaded redo log destinations

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Workshop

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Objectives

After completing this lesson, you should be able to do the following:• Explain the workshop methodology• Explain the workshop setup

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Workshop Premise

• You are the DBA of a growing company that has decided to implement Oracle Data Guard to protect its Oracle database.

• You use Enterprise Manager and SQL commands to manage your Data Guard configuration.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Workshop Flow

In this workshop, you perform the following tasks:• Create one or more standby databases.• Verify the configurations.• Change the protection mode.• Retrieve information from the standby database.• Perform failovers.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Workshop Scenarios

The workshop comprises the following scenarios:1. Creating a Data Guard configuration to ensure high

availability, data protection, and disaster recovery2. Verifying the configuration and the operation of log

transport and apply services3. Verifying that the automatic gap detection and

resolution feature is working properly4. Changing the protection mode to meet stated

requirements

General Notes for the WorkshopThe scenarios should be performed in order.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Workshop Scenarios

5. Configuring the feature that will ensure you will not need to re-create the primary database after failover

6. Adding a data file to your primary database7. Configuring the standby database so that users can

use it for reporting 8. Adding a standby database that will support reporting9. Verifying that the automatic gap detection and

resolution feature is working properly

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Workshop Scenarios

10.Configuring SQL Apply so that specified DML statements are not executed on the logical standby database

11.Creating a new view on the logical standby database12.Performing a failover operation13.Adding your original primary database back into the

configuration14.Returning to your original Data Guard configuration

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y



Summary

In this lesson, you should have learned:• The flow of the workshop• The setup that is used for the workshop• Some hints that will help you through the workshop

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Workshop PreparationTo prepare for the workshop, you need to drop your Data Guard configuration and your standby databases. Perform the following steps:

1. Access the Data Guard page and disable fast-start failover.2. Change the protection mode from Maximum Availability to Maximum Performance.3. Drop your Data Guard configuration by selecting Remove Data Guard Configuration in the

Additional Administration section. Click Yes on the Confirmation: Remove Data Guard Configuration page to confirm.

4. Invoke DBCA on the server machine your standby databases are on and delete your standby databases.

5. Remove your <HOSTNAME>_SITE1 and <HOSTNAME>_SITE2 databases from Grid Control.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Workshop ScenariosIn the workshop you will create standby databases and modify your configuration to meet the business requirements outlined in the workshop scenarios.

1. You need to create a Data Guard configuration to ensure high availability, data protection, and disaster recovery for your enterprise data. You want to be able to open your standby database in read-only mode so that queries can be executed. Create your standby database to meet these requirements with the following specifications:Standby database unique and target name: <YOUR_HOSTNAME>_SITE1Location: Create your standby database on the next-highest student PC in your classroom. For example, if your host name is EDRSR8P1, create your physical standby database named EDRSR8P1_SITE1 on EDRSR8P2. If you are on EDRSR8P12, create your standby database on EDRSR8P1.

2. You want to ensure that you have created your standby database successfully and that the log transport and apply services are working. Use Enterprise Manager to confirm that your Data Guard configuration is functioning properly.

3. You understand that Data Guard can automatically detect archive gaps and resolve those gaps by copying the missing sequence of log files to the standby destination. As an example, if connectivity is lost between the primary and one or more standby databases (for example, due to network problems), redo data being generated on the primary database cannot be sent to those standby databases. Once a connection is reestablished, the missing archived redo log files (referred to as a gap) are automatically detected by Data Guard, which then automatically transmits the missing archived redo log files to the standby databases. Verify that this feature is working properly in your configuration by simulating a loss of connectivity. Disable log transport services to your standby database, switch the log on your primary database, and reenable log transport services to your standby database.

4. Maximum performance is the default protection mode and provides the highest level of data protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. You have determined that you need to change the data protection mode to ensure the redo data needed to recover each transaction is written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits. You also want to configure the protection mode so that the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Change the protection mode so that your configuration meets these requirements.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Workshop Scenarios (continued)5. You want to ensure that you will not need to re-create the primary database after you have

performed a failover operation. Configure the feature that will enable you to flash back the failed primary database to a point in time before the failover and convert it into a standby database for the new primary database.

6. You have been asked to add a data file to the EXAMPLE tablespace in your primary database. Add the data file with the following specifications:Data file name: /u01/app/oracle/oradata/orcl/example02.dbfData file size: 2 MBVerify that the new data file has been added to your standby database.

7. The application users need to run some additional reports and do not want to impact the production system. Perform the steps required to make the standby database available for this reporting task. Verify that you can query tables in the standby database and then restart real-time apply so that the standby database will be resynchronized with the primary database.

8. You have determined that the users will need to run reports on a regular basis and do not want to impact the production database. In addition, you would like to add a standby database to your configuration for additional data protection. Configure a second standby database that will be available for users to perform queries, summations, and reporting activities against at all times with the following specifications:Standby database unique and target name: <HOSTNAME>_SITE2Location: Create your standby database on the next-highest student PC in your classroom. For example, if your host name is EDRSR8P1, create your standby database on EDRSR8P2. If you are on EDRSR8P12, create your standby database on EDRSR8P1.

9. Verify that the automatic gap detection and resolution feature is working properly in your configuration by simulating a loss of connectivity to your new standby database. Disable log transport services to your standby database, switch the log on your primary database, and reenable log transport services to your standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Workshop Scenarios (continued) 10. Because the users want to use some tables in the new standby database to report against for

historical purposes, you need to configure SQL Apply so that certain DML statements are not executed against those tables on the logical standby database. You decide to test this feature first by creating a new table on the primary database as follows:

CREATE TABLE hr.emp_name AS SELECT first_name, last_name

FROM hr.employees WHERE 1=2;

Define a filter that prevents SQL Apply from issuing DML statements against the HR.EMP_NAME table on the logical standby database. Insert a few rows into the HR.EMP_NAME table on the primary database and commit your changes. Force a log switch on the primary database and then verify that the new rows are not applied to your logical standby database.

11. You have been asked to create a view for the users to query on the logical standby database. Create the view as follows:

CREATE VIEW hr.emp_90_vw AS SELECT *

FROM hr.employees WHERE department_id=90;

12. You have experienced a failure on your primary database server. Fail over to your physical standby database.

13. You have been able to restore the server which your primary database was on. Add your original primary database back into your Data Guard configuration as a physical standby database.

14. Return to your original Data Guard configuration with your HOSTNAME_ORCL.oracle.com database as your primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Appendix APractices and Solutions

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

Oracle Database 10g: Data Guard Administration A - 2

Practice 1: Oracle Data Guard Overview1. Which one of the following statements is true?

a. A standby database is a set of log files that will be applied in the event of a system failure.b. A primary database is the production database.c. A logical standby is an extension to the physical standby database.d. The redo logs contain native SQL that can be applied to the standby database.

Solution: b

2. Which one of the following is not an Oracle Data Guard service?a. Role managementb. Redo transportc. Redo logd. Log apply

Solution: c

3. Which one of the following operations would you perform when the primary database is completely lost?

a. Switchoverb. Apply backups to standbyc. Apply redo logsd. Failover

Solution: d

4. The Oracle Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations.

a. Trueb. False

Solution: a

5. Enterprise Manager provides monitoring, automation, and management of the Data Guard broker components.

a. Trueb. False

Solution: a

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 1: Oracle Data Guard Overview (continued)6. Which protection mode will cause the primary database to be shut down if contact with all

standby databases is lost?a. Maximum protectionb. Maximum availabilityc. Maximum performance

Solution: a

7. Which protection mode has the lowest impact on the performance of the primary database but has the possibility of data loss?

a. Maximum protectionb. Maximum availabilityc. Maximum performance

Solution: c

8. Real Application Clusters and Oracle Data Guard should not be used together because they basically do the same thing.

a. Trueb. False

Solution: b

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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

a. The ARCn process creates a copy of the online redo logs for use by the LGWR process.b. The LGWR process collects transaction redo and updates the data files.c. The FAL process provides a client/server mechanism for resolving gaps that are detected in

the range of archive redo logs.d. The MRP process applies archived redo log information to the logical standby database.

Solution: c

2. Which one of the following is not an operational requirement for the Data Guard environment?a. The primary and standby databases must use the same database release.b. Each primary and standby database must have its own control file.c. The primary database must operate in ARCHIVELOG mode.d. The standby must be on the same node as the primary.

Solution: d

3. What are the modes of a physical standby database?______________________________________________________________________________________________________________

Solution: Managed recovery and open read-only

4. What technology is used to transform the redo log into SQL?______________________________________________________________________________________________________________

Solution: LogMiner

5. Should you create standby redo logs on the primary database?______________________________________________________

Solution: Yes

6. How many standby redo log groups should you have?_____________________________________________________________________________________________________________

Solution: At a minimum, the number of standby redo log groups should be equal to the number of online redo log file groups on the primary database; one more (per primary database instance) than this is recommended.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 2-2: Installing the Oracle Management Agent Oracle Enterprise Manager Grid Control is installed and operational on a server for your practices. You must install the Oracle Management Agent on your PC so that you can use Grid Control to monitor, configure, and administer the databases on your PC.

1. Open a terminal window and log on as the oracle user with a password of oracle.

2. Oracle Enterprise Manager Grid Control software is staged in the agent_installmediadirectory. Change directories to agent_installmedia/Disk1/linux/agent.

[oracle@EDRSR10P1 oracle]$ cd agent_installmedia/Disk1/linux/agent

3. Set your $ORACLE_HOME environment variable by executing the export command.

[oracle@EDRSR10P1 oracle]$ export ORACLE_HOME=$AGENT_HOME[oracle@EDRSR10P1 oracle]$ echo $ORACLE_HOME/u01/app/oracle/product/10.2.0/agent10g

4. Invoke the Oracle Universal Installer by issuing the following command:

./runInstaller

5. On the Specify Installation Type page, select Additional Management Agent. Click Next.

6. On the Specify Installation Location page, specify /u01/app/oracle/product/10.2.0in the Parent Directory field. Click Next.

7. On the Product Specific Prerequisite Checks page, select the check box next to Status to manually verify the warning. The status changes to User Verified. Click Next.

8. On the Specify Oracle Management Service Location page, enter the following information about the host machine that Oracle Enterprise Manager Grid Control is installed on:Management Service Host Name: <OMS_host> (Example:ex0026.oracle.com)Management Service Port: 4889

Click Next.

9. On the Specify Agent Registration Password page, specify oracle1 in the Password field. Click Next.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 2-2: Installing the Oracle Management Agent (continued)10. On the Oracle Configuration Manager Agreement page, select Decline License Agreement.

Click Next.

11. Click OK on the warning page.

12. Click Install on the Summary page. The Install page appears showing the progress of the installation.

13. The “Execute Configuration scripts” dialog box appears. Follow the instructions to execute the root.sh script. Open a new terminal window, log in as the root user, change to the specified directory, and execute the root.sh script.[oracle@EDRSR10P1 oracle]$ su -Password: [root@EDRSR10P1 root]# cd /u01/app/oracle/product/10.2.0/agent10g[root@EDRSR10P1 root]# ./root.sh

Accept the default values for all prompts during the execution of the root.sh script.After the root.sh script completes, return to the “Execute Configuration scripts” dialog box and click OK.

14. The Configuration Assistants page appears. Once the configuration is complete, the “End of Installation” page appears. Verify that the installation was successful and click Exit to exit the Oracle Universal Installer. Click Yes in the Exit dialog box.

15. Configure monitoring credentials for your database. Open your browser and enter the following URL:

http://<oms_host>:7777/em

16. Log in as the user sysman with password oracle1, and change the Monitor Password for your database to oracle.

a. Log in as the user sysman with password of oracle1 and click Login.b. Review the licensing information and click “I agree.”c. Select Targets and click Databases.d. Select your database (<HOSTNAME>_ORCL) from the list of databases and click

Configure.e. Enter the Monitor Password of oracle and click Test Connection.f. Verify that the connection is successful and click Next. Click Submit.g. Click OK on the Database Instance Configuration Result page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 2-3: Configuring Your Primary Database As you proceed through the remaining practices, use this page to record information about your databases.

Primary DatabaseDatabase Name: ___________________________________________________Instance Name: ____________________________________________________Database Unique Name: _____________________________________________Target Name: _____________________________________________________Host: ____________________________________________________________Oracle Home: _____________________________________________________

Standby DatabaseDatabase Name: ___________________________________________________Instance Name: ____________________________________________________Database Unique Name: _____________________________________________Target Name: _____________________________________________________Host: ____________________________________________________________Oracle Home: _____________________________________________________ Type of standby: ___________________________________________________


Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 2-3: Configuring Your Primary Database (continued)IMPORTANT NOTE: PLEASE USE PAGE A-7 TO RECORD INFORMATION ABOUT THE SYSTEMS YOU WILL USE AND DATABASE NAMES.

1. Invoke Enterprise Manager Grid Control and view your database home page.a. Enter the URL supplied by your instructor: http://hostname:7777/emb. Supply the following to log in to Grid Control:

User name: SYSMANPassword: _________

c. Click Login.d. Click Targets to access the Hosts page. e. Click Databases to access the Databases page.f. Select your database by clicking the database link name.

Important: Because you are logging in as the SYSMAN user, you will be able to see and modify all databases in your classroom. Be careful as you select only your database in the list.

2. Configure preferred credentials for your database.a. Access your database home page.b. Click Preferences in the top-right corner.c. Click Preferred Credentials on the left side.d. Click the Set Credentials icon for the Database Instance target type.e. Locate your database in the Target Credentials region and enter the usernames and

passwords as follows: Normal username: SYSTEMNormal password: oracleSYSDBA username: SYSSYSDBA password: oracleHost username: oracleHost password: oracle

f. Click Test to verify your entries. You receive the message “Credentials successfully verified for <database instance name>.” If you do not receive this message, correct your errors and click Test again.

g. Click Apply to confirm your entries. You receive the message “Credential changes successfully applied.”

h. Click Targets. Click Databases to return to the Databases page.

Note: Practice 2-3 continues on the next page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 2-3: Configuring Your Primary Database (continued) 3. Configure ARCHIVELOG mode for your database. Use the flash recovery area for the archive

log destination. Do not set up any other destinations at this time. In addition, configure Flashback Database for your database. You must be logged in as SYSDBA to complete this task.

a. Select your database on the Databases page. On your database home page, click Maintenance to access the Maintenance page.

b. Click Recovery Settings to access the Configure Recovery Settings page.c. Because you are logged in as SYSTEM, the Database Login page is displayed. If the

Database Login page does not display, click Logout in the upper-right corner of the page. Select “Log out of database” and “Display database login page after logout.”

d. Enter the username SYS, password ORACLE, and select SYSDBA from the “Connect As” drop-down menu. Click Login.

e. Select “ARCHIVELOG Mode” in the Media Recovery section.f. Accept the default of USE_DB_RECOVERY_FILE_DEST in destination 10 to indicate

that the flash recovery area should be used.g. Select “Enable Flashback Database - flashback logging can be used for fast database point-

in-time recovery*.”h. Enter 12 hours in the Flashback Retention Time field.i. Click Apply.j. Click Yes on the confirmation page to restart the database instance.k. Confirm the host and database credentials or enter them if required. Click OK.l. Click Yes to restart the database instance after shutdown.m.An Update Message is displayed confirming your change.n. Click the Database Instance link to return to the Maintenance page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 4: Creating a Physical Standby Database by Using Enterprise Manager1. Invoke Enterprise Manager 10g Grid Control and access your database home page.

a. Enter the URL supplied by your instructor: http://hostname:7777/emb. Supply the following to log in to Grid Control:

User name: SYSMANPassword: _________

c. Click Login.d. Click Targets to access the Hosts page. e. Click Databases to access the Databases page.f. Click the link for your database to access the database home page.

Practice 4 continues on the next page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 4: Creating a Physical Standby Database by Using Enterprise Manager (continued)

2. Create a physical standby database with the following specifications by using Grid Control:Primary database unique name: <HOSTNAME>_ORCLStandby database unique and target name: <HOSTNAME>_SITE1Location: Create your physical standby database on the next highest student PC in your classroom. For example, if your host name is EDRSR8P1, create your physical standby database named EDRSR8P1_SITE1 on EDRSR8P2. Note: Your instructor may modify this configuration. Use the naming conventions provided above to avoid confusion when selecting your databases in Grid Control. Record information on page A-7.

a. Access your database home page and select Maintenance to access the Maintenance page.b. Click Setup and Manage in the Data Guard section.c. Provide the SYSDBA login information on the Database Login page if requested.c. Click Add Standby Database to invoke the Add Standby Database Wizard.d. Select “Create a new physical standby database” and click Continue.e. Select “Perform a live backup of the primary database” and click Next.f. Accept the default location for the backup and the default option to delete the working

directory after the standby creation. If the password field is empty, provide the password for the Oracle server owner user and select Save as Preferred Credential. Click Next.

g. Accept the default instance name of dg2. Enter the credentials for the standby host machine if they differ from the default supplied. Select the host in the Standby Database Location section as described above. Click Next.

h. Accept the default, to transfer files, in the Standby Host Backup File Access section. Select “Convert to Oracle OFA” in the Standby Database File Locations section. Accept the default location for the network configuration file location. Click Next.

i. If you receive the following warning message: “The following files already exist and will be overwritten: /u01/app/oracle/product/10.2.0/db_1/demo/schema/sales_history/sale1v3.dat; Click ‘Yes’ to continue, or click ‘No’ then ‘Customize’ to make changes.”, click Yes to continue.

j. Specify Database Unique Name and Target Name as <HOSTNAME>_SITE1. Accept the default location for the archived redo logs. Click Next.

k. Review your configuration information and click Finish.l. After you are returned to the Data Guard page, select “Real Time: 1 Minute Refresh” from

the View Data drop-down menu to monitor the creation of your standby database. Click “Creation in progress” to view detailed information about the creation of your physical standby database. The creation is complete when the status changes to Normal.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 4: Creating a Physical Standby Database by Using Enterprise Manager (continued)

3. After the physical standby creation is complete, use Verify to validate the configuration and add standby redo logs.

a. Access your Data Guard configuration by selecting your primary database. Select Setup and Manage in the Data Guard section of the Maintenance page.

b. Click Verify Configuration in the Additional Administration section.c. Review the information in the “Detailed Results” section.d. Select “Create standby redo logs for the following database(s)” to create standby redo logs

for your primary and standby databases. Click OK.

4. Enable Flashback Database for your physical standby database, setting the retention time to 12 hours as follows:

a. Navigate to the Maintenance page for your physical standby database.b. Select Recovery Settings in the Backup/Recovery Settings section of the Maintenance

page.c. Supply SYSDBA login information. Click Login.d. Select “Enable Flashback Database-flashback logging can be used for fast database point-

in-time recovery.”e. Enter 12 hours in the Flashback Retention Time field.f. Click Apply.g. Click Yes to restart the database instance.h. Enter the Host Credentials and Database Credentials if they are not supplied. Click OK.i. Click Yes to restart the database instance.j. Return to the database home page after the database instance has been restarted.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 6: Configuring Data Protection Modes and Redo Transport Services1. Using Enterprise Manager, change the data protection mode for your standby database to

maximum protection.a. On the Databases target page, click the link for your primary database.b. Click Maintenance.c. Click Setup and Manage in the Data Guard section.d. In the Overview section, click the link in the Protection Mode field to access the Change

Protection Mode: Select Mode page. e. Select Maximum Protection and click Continue.f. Accept the default selection of your physical standby database and click Continue.g. If requested, supply the host login credentials and click Continue.h. Click Yes on the Confirmation: Change Protection Mode page.i. The Processing: Change Protection Mode page is displayed.j. You are returned to the Data Guard Overview page. Verify that your protection mode has

been changed to maximum protection.

2. Using Enterprise Manager, configure a delay for the application of redo to the standby database to allow you to stop the application of any corrupt data. Set the delay for 2 hours (120 minutes).

a. Select your standby database and click Edit on the Data Guard page.b. Click Standby Role Properties on the Edit Standby Database Properties page.c. Enter the delay value of 120 in the Apply Delay field.d. Click Apply. You receive the “All changes successfully applied.” message.

3. In preparation for later practices, use Enterprise Manager to change the data protection mode back to maximum performance.

a. Navigate to the Data Guard page.b. Click the link in the Protection Mode field to access the Change Protection Mode: Select

Mode page. c. Select Maximum Performance and click Continue.d. Click Yes on the Confirmation: Change Protection Mode page.e. You are returned to the Data Guard Overview page and the “Confirmation The protection

mode has been successfully changed.” message is displayed.

4. You decide that you no longer want the delayed application of redo. Use Enterprise Manager to disable the delay in the application of redo.

a. Select your standby database and click Edit on the Data Guard page.b. Click Standby Role Properties on the Edit Standby Database Properties page. c. Enter the delay value of 0 in the Apply Delay field.d. Click Apply. You receive the “Success All changes successfully applied.” message.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 7: Creating a Logical Standby Database by Using Enterprise Manager1. Use Enterprise Manager Grid Control to create a logical standby database with the following

specifications:Standby database unique and target name: <HOSTNAME>_SITE2Location: Create your logical standby database on the next highest student PC in your classroom. For example, if your host name is EDRSR8P1, create your logical standby database named EDRSR8P1_SITE2 on EDRSR8P2. Note: Your instructor may modify this configuration. Use the naming conventions provided above to avoid confusion when selecting your databases in Grid Control. Record information on page A-7.

a. Select your primary database on the Databases target page.b. Select Maintenance to access the Maintenance page.c. Click Setup and Manage in the Data Guard section.d. Click Add Standby Database in the Standby Databases section to invoke the Add Standby

Database Wizard.e. Select “Create a new logical standby database” and click Continue.f. Select “Perform a live backup of the primary database” and click Next.g. Accept the default location for the backup and the default option to delete the directory

after the standby creation. Enter primary host credentials if needed. Click Next.h. On the Database Location page, accept the default instance name of dg3. Enter the

credentials for the host machine if they differ from the default supplied. Select the host in the Standby Database Location section as described above. Click Next.

i. Accept the default, to transfer files, in the Standby Host Backup File Access section. Select “Convert to Oracle OFA” in the Standby Database File Locations section. Accept the default location for the network configuration file location. Click Next.

j. If you receive the warning message “Warning: The following files already exist and will be overwritten: /u01/app/oracle/product/10.2.0/db_1/demo/schema/sales_history/sale1v3.dat; Click ‘Yes’ to continue, or click ‘No’ then ‘Customize’ to make changes.”, click Yes.

k. Accept the default Database Name. Specify Database Unique Name and Target Name as <HOSTNAME>_SITE2. Accept the default location for the archived redo logs. Click Next.

l. Review your configuration information and click Finish. You may see an “ORA-16821-logical standby database dictionary not yet loaded” warning message. Wait until you see the “normal” status.

m.Select “Real Time: 1 Minute Refresh” in the View Data drop-down menu to monitor the creation.

2. After the logical standby database creation is complete, use Verify to validate the configuration.a. Select Setup and Manage in the Data Guard section of the Maintenance page. Access your

Data Guard configuration by selecting your primary database. b. Click Verify Configuration in the Additional Administration section.c. View progress on the Processing: Verify page.d. Review results in the Detailed Results window. Click OK to return to the Data Guard page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 7: Creating a Logical Standby Database by Using Enterprise Manager (continued)

3. Enable Flashback Database for your logical standby database, setting the retention time to 12 hours as follows:

a. Navigate to the Maintenance page for your logical standby database.b. Click Recovery Settings in the Backup/Recovery Settings section of the Maintenance

page.c. Specify the following to configure the Flash Recovery Area:

Flash Recovery Area: /u01/app/oracle/product/10.2.0/db_1/oradata/dg3/arcFlash Recovery Size: 3106 MB

d. Select “Enable Flashback Database-flashback logging can be used for fast database point-in-time recovery.”

e. Enter 12 hours in the “Flashback Retention Time” field.f. Click Apply.g. Click Yes to restart the database instance.h. Enter the Host Credentials and Database Credentials if they are not supplied. Click OK.i. Click Yes to restart the database instance.j. Return to the database home page after the database instance has been restarted.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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

Schema: HRName: MY_TABLEColumn Name: COL1 Data type: NUMBERTablespace: EXAMPLE

a. Select your primary database on the Databases target page.b. Select Tables in the Schema section of the Administration page.c. Supply login information (SYS/ORACLE, Connect as SYSDBA) and click Login.c. Click Create.d. Select Standard, Heap Organized and then click Continue.e. Enter the table name, schema, tablespace name, and column information. Click OK. You

receive a confirmation message: “Update Message Table HR.MY_TABLE has been created successfully.”

2. Perform a log switch on your primary database.a. Return to your primary database home page by clicking the database instance link. b. Click Redo Log Groups in the Storage section of the Administration page.c. Select “Switch logfile” in the Actions list.d. Click Go. You receive the “Update Message Log group successfully switched.” message.

3. Access the Data Guard page for your configuration. a. Return to the Administration page for your primary database by clicking on the database

instance link.b. Access the Maintenance page. Select Setup and Manage in the Data Guard section.

4. Select your physical standby database and perform a switchover.a. Select your physical standby database and click Switchover.b. Supply host login credentials and click Login.c. Click Yes to confirm the switchover operation.d. View the progress on the Processing: Switchover page.e. You are returned to the Data Guard page and receive the “Information Switchover

completed successfully” message.

5. Verify that the HR.MY_TABLE table you created in step 1 exists on your new primary database.

a. Access the database home page for your new primary database.b. Select Tables in the Schema section of the Administration page.c. Log in to your database as SYS with a password of ORACLE as SYSDBA.d. Enter HR in the Schema field and MY_TABLE in the Object Name field.e. Click Go.f. The table is displayed in the table list.

Note: Practice 9 continues on the next page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


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

a. Navigate to the Data Guard page.b. Select your physical standby database and click Failover.c. On the confirmation page, click Yes to proceed with the failover.d. Supply host login credentials. Click Continue.e. Select Complete for the type of failover and click Yes.f. The Processing: Failover page is displayed. When the failover is completed, you are

returned to the Data Guard page and receive the “Information Failover completed successfully” message.

7. Attempt to reinstate the former primary database (HOSTNAME_SITE1).a. Click the “Database must be reinstated” link for your <HOSTNAME>_SITE1 database.b. On the Edit Standby Database Properties: <HOSTNAME>_SITE1 page, click Reinstate.c. Provide the SYSDBA login credentials (SYS/ORACLE). Click Yes to restart the instance.

The “Information Database <HOSTNAME>_SITE1 has been successfully started.” message is displayed and you are returned to the Data Guard page.

d. Again, click the “Database must be reinstated” link.e. Click Reinstate.f. Supply SYSDBA login credentials again if requested and click Yes.g. The Processing: Reinstating Database page is displayed. Once complete, you are returned

to the Data Guard page and receive the “Information Database <HOSTNAME>_SITE1 has been successfully reinstated.” message.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 10: Enabling Fast-Start Failover1. Use Enterprise Manager to enable fast-start failover to your physical standby database.

a. Access the Data Guard page.b. In the Overview section, click the Disable link next to “Fast-Start Failover.”c. In the Target Database Selection section, select your physical standby database

(<HOSTNAME>_SITE1).d. In the Properties section, click “Set Observer.” The Fast-Start Failover: Set Observer

page appears.e. Click the flashlight icon next to the Observer Host field to select the host machine for

the observer. For the purposes of this practice, select the same host that your physical standby database is on.

f. Click OK to accept the selected Observer Host and Observer Oracle Home. Because you are using the same host for the observer, you will receive a warning message: “You have chosen to start the observer on the same host where the primary or standby database is located. Oracle recommends the observer be on a separate host.”

g. The Fast-Start Failover: Configure page displays again with the specified Observer Location. Set the Fast-Start Failover Threshold to 90 seconds. Click Continue.

h. On the Observer Host Credentials page, supply the operating system user name of oracle and password of oracle for the observer host. Click Continue.

i. On the Confirmation: Enable Fast-Start Failover page, click Yes.j. The Processing: Enable Fast-Start Failover page displays. After processing completes

(which may take some time), the Data Guard overview page displays with the “Information The fast-start failover mode has been successfully changed and the primary database has been restarted.” message. Note that the Fast-Start Failover field indicates that fast-start failover is enabled.

2. In preparation for later steps, access the Data Guard configuration through your physical standby database.

a. Click the Databases subtab.b. Click your physical standby database.c. Click Maintenance. Click Setup and Manage in the Data Guard section.

3. Shut down your primary database to simulate a failure.a. Open a terminal window to the host your primary database is on and log in as the oracle user.

b. Invoke SQL*Plus and connect as the SYS user with SYSDBA privileges as follows:sqlplus / as sysdba

Note: If you receive an error regarding ORACLE_HOME, set it to: /u01/app/oracle/product/10.2.0/db_1

c. Shut down the database with the ABORT option:SQL> shutdown abort

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 10: Enabling Fast-Start Failover (continued)4. Return to the Data Guard page for your configuration to monitor the fast-start failover.

a. Set the View Data field to Real Time: 1 Minute Refresh.b. Note that the Data Guard status has turned to “Error.” and “ORA-16625: cannot reach

the database” is displayed.c. Continue monitoring the Data Guard page until your former physical standby database

is shown as the primary database.

5. Restart your primary database.a. Return to your terminal window.b. Restart your database instance:

SQL> connect / as sysdbaConnected to an idle instance.SQL> startup

6. Return to Enterprise Manager to monitor your configuration as the new physical standby database is added back into the configuration.

7. In preparation for later practices, perform a switchover to your physical standby database (<HOSTNAME>_ORCL.oracle.com)

a. Select your physical standby database (<HOSTNAME>_ORCL.oracle.com). Click Switchover.

b. On the Confirmation: Switchover to <HOSTNAME>_ORCL.oracle.com, click Yes. The Processing: Switchover page is displayed.

c. After the switchover is complete, you are returned to the Data Guard page. Confirm that your <HOSTNAME>_ORCL.oracle.com database is listed as your primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop PreparationTo prepare for the workshop, you need to drop your Data Guard configuration and your standby databases. Follow the steps below to accomplish these tasks.

1. Access the Data Guard page and disable fast-start failover.a. Select the link next to Fast-Start Failover in the Overview section.b. Select “Disable” and “Stop observer” on the Fast-Start Failover: Change Mode page. Click

Continue.c. Click Yes on the confirmation page.

2. Change the protection mode from Maximum Availability to Maximum Performance.a. Click “Maximum Availability” next to Protection Mode in the Overview section.b. Select “Maximum Performance” and click Continue.c. Click Yes on the confirmation page.

3. Drop your Data Guard configuration by selecting Remove Data Guard Configuration in the Additional Administration section. Click Yes on the Confirmation: Remove Data Guard Configuration page to confirm. The “Confirmation The Data Guard configuration has been removed.” message is displayed.

4. Remove your <HOSTNAME>_SITE1 and <HOSTNAME>_SITE2 databases from Grid Control.

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

5. Open a terminal window and telnet to the machine your standby databases are on. Log in as the oracle user with password of oracle. Invoke DBCA on the server machine your standby databases are on and delete your standby databases. Invoke DBCA by entering dbca at the command prompt.

a. Open a terminal window and log in as the oracle user.b. Enter the command: xhost +c. Telnet to the machine your standby databases are on: telnet <hostname>d. Invoke DBCA by entering dbca at the command prompt.a. Click Next on the DBCA Welcome page.b. On the Step 1 of 2: Operations page, select “Delete a Database” and click Next.c. On the Step 2 of 2: Database page, select “dg2” and click Finish.d. Click Yes to confirm the deletion.e. Click Yes to perform another operation.f. Repeat the deletion steps for “dg3.”g. After you complete the deletion of dg3, click No to exit DBCA.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop As you proceed through the workshop, use this page to record information about your databases.

Primary DatabaseDatabase Name: ___________________________________________________Instance Name: ____________________________________________________Database Unique Name: _____________________________________________Target Name: _____________________________________________________Host: ____________________________________________________________Oracle Home: _____________________________________________________



Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios1. You need to create a Data Guard configuration to ensure high availability, data protection, and

disaster recovery for your enterprise data. You want to be able to open your standby database in read-only mode so that queries can be executed. Create your standby database to meet these requirements with the following specifications:Standby database unique and target name: <YOUR_HOSTNAME>_SITE1Location: Create your standby database on the next highest student PC in your classroom. For example, if your host name is EDRSR8P1, create your physical standby database named EDRSR8P1_SITE1 on EDRSR8P2.Note: Your instructor may modify this configuration. Use the naming conventions provided above to avoid confusion when selecting your databases in Grid Control. Record information on page A-18.

a. Select your primary database on the Databases page.b. Click Setup and Manage in the Data Guard section of the Maintenance page.c. On the Data Guard page, click Add Standby Database.d. Select “Create a new physical standby database” and click Continue.e. Select “Perform a live backup of the primary database” and click Next.f. Accept the default location for the Backup Files Directory Location. Enter the Primary

Host Credentials if not already populated. Click Next.g. Accept the default instance name. Select the host for the Standby Database Location (as

instructed above) and click Next.h. Select “Transfer files from the primary host backup files directory to a standby host

directory” and “Convert to OFA.” Click Next.i. Click Yes for the “The following files already exist and will be overwritten:

/u01/app/oracle/product/10.2.0/db_1/demo/schema/sales_history/sale1v3.dat; Click ‘Yes’to continue, or click ‘No’ then ‘Customize’ to make changes.” warning message.

j. Change the Database Unique Name and Target Name to <YOUR_HOSTNAME>_SITE1 as described above. Accept the default for the Standby Archive location. Click Next.

k. Review the information and click Finish.l. When the Data Guard page reappears, select Real Time: 1 Minute Refresh from the View

Data drop-down menu. You can also click the link in the Status column to review additional information.

2. You want to ensure that you have created your standby database successfully and that the redo transport and apply services are working. Use Enterprise Manager to confirm that your Data Guard configuration is functioning properly.

a. Click Verify Configuration in the Additional Administration section of the Data Guard page.

b. Click OK to create standby redo logs.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)3. You understand that Data Guard can automatically detect archive gaps and resolve those gaps

by copying the missing sequence of log files to the standby destination. As an example, if connectivity is lost between the primary and one or more standby databases (for example, due to network problems), redo data being generated on the primary database cannot be sent to those standby databases. Once a connection is reestablished, the missing archived redo log files (referred to as a gap) are automatically detected by Data Guard, which then automatically transmits the missing archived redo log files to the standby databases. Verify that this feature is working properly in your configuration by simulating a loss of connectivity. Disable redo transport services to your standby database, switch the log on your primary database, and reenable redo transport services to your standby database.

a. Disable redo transport services as follows:On the Data Guard page, select the standby database and click Edit.Click the Standby Role Properties tab. Expand Show Advanced Properties. Select OFF in the Log Shipping drop-down menu. Click Apply. Select the Databases targets tab.

b. Force three to five log switches on the primary database as follows:Click the link for your primary database on the Databases targets tab.Click Redo Log Groups on the Administration page for the primary database. Select Switch Logfile in the Actions drop-down menu and click Go. Repeat three to five times.Return to the Data Guard page and observe the difference in the current log number for the primary database and the last received log for the standby database.

c. Enable redo transport services to the physical standby database as follows:On the Data Guard page, select the standby database and click Edit. Select the Standby Role Properties page. Expand Show Advanced Properties. Select ON in the Log Shipping drop-down menu. Click Apply.

d. Verify that all redo has been applied as follows:Return to the Data Guard page and observe that the standby database has received the redo log files from the primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)4. Maximum performance is the default protection mode and provides the highest level of data

protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. You have determined that you need to change the data protection mode to ensure the redo data needed to recover each transaction is written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits. You also want to configure the protection mode so that the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Change the protection mode so that your configuration meets these requirements. Change the protection mode to maximum availability as follows:

a. On the Data Guard page, click the link in the Protection Mode field.b. Select Maximum Availability and click Continue.c. Click Continue on the Change Protection Mode: Standby Databases and Standby Redo Log

Files page.d. Click Yes on the Confirmation: Change Protection Mode page.e. After the protection mode is changed you are returned to the Data Guard page and receive

a confirmation message.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)5. You want to ensure that you will not need to re-create the primary database after you have

performed a failover operation. Configure the feature that will enable you to flash back the failed primary database to a point in time before the failover and convert it into a standby database for the new primary database. Enable Flashback Database for your primary database, setting the retention time to 12 hours as follows:

a. Navigate to the Maintenance page for your primary database.b. Select Recovery Settings in the Backup/Recovery Settings section of the Maintenance page.c. Verify that the “Enable Flashback Database-flashback logging can be used for fast database

point-in-time recovery.” feature is selected. If it is not, select it at this time.d. Enter 12 hours in the “Flashback Retention Time” field.e. Click Apply. You receive an Update Message if the feature was previously enabled. Skip to

step i. Otherwise, complete steps f – i.f. Click Yes to restart the database instance.g. Enter the Host Credentials and Database Credentials if they are not supplied. Click OK.h. Click Yes to restart the database instance.i. Return to the database home page after the database instance has been restarted.

6. You have been asked to add a data file to the EXAMPLE tablespace in your primary database. Add the data file with the following specifications:Data file name: /u01/app/oracle/oradata/orcl/example02.dbfData file size: 2 MBVerify that the new data file has been added to your standby database.

a. Add the new data file as follows:Select the primary database. Select Tablespaces in the Storage section of the Administration page. Select the EXAMPLE tablespace. Select Add Datafile in the Actions drop-down menu and click Go. Enter example02.dbf in the File Name field and 2 MB in the File Size field. Click OK.An update message is displayed.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)b. Force a log switch as follows:

Return to your primary database home page.Select Redo Log Groups on the Administration page for the primary database. Select Switch Logfile in the Actions drop-down menu and click Go.

c. Verify that the new data file was added to the standby database as follows:Open a terminal window and telnet to the machine your standby database is on. Log in as the oracle user with a password oracle. Set the ORACLE_SID environment variable to dg2. You must start a SQL*Plus session to verify that the new data file was added to the standby database. Because the database is in MOUNT mode, Enterprise Manager does not display the tablespaces and datafiles. Issue the following query to verify that the file was added and then exit from SQL*Plus:SELECT name FROM v$datafile;

Sample output is as follows:[oracle@EDRSR4P1 oracle]$ export ORACLE_SID=dg2

[oracle@EDRSR4P1 oracle]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.2.0 - Production on Wed Aug 23 12:49:10 2006

Copyright (c) 1982, 2005, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 -Production

With the Partitioning, Oracle Label Security, OLAP and Data Mining options

SQL> SELECT db_unique_name FROM v$database;

DB_UNIQUE_NAME

------------------------------

EDRSR10P1_SITE1

SQL> SELECT name FROM v$datafile;

NAME

----------------------------------------------------------

/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/system01.dbf

/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/undotbs01.dbf

/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/sysaux01.dbf

/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/users01.dbf

/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/example01.dbf

/u01/app/oracle/product/10.1.0/db_1/oradata/dg2/example02.dbf

6 rows selected.

SQL> exit

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)7. The application users need to run some additional reports and do not want to impact the

production system. Perform the steps required to make the standby database available for this reporting task. Verify that you can query tables in the standby database and then restart log apply services so that the standby database will be resynchronized with the primary database.

a. On the Data Guard page, select the standby database and click Edit. b. Select “Read Only” in the Log Apply Services section. Click Apply. You receive the “All

changes successfully applied.” message.c. Return to the Data Guard page and verify the status of “Normal, Read Only” for your

standby database.d. Open a terminal window and telnet to the machine your standby database is on. Log in as

the oracle user with the password oracle. Set the ORACLE_SID environment variable to dg2. Invoke SQL*Plus. Connect as the HR user and query the HR.EMPLOYEES table as follows:SQL> SELECT count(*) FROM employees;


[oracle@EDRSR4P1 oracle]$ sqlplus hr/hr



Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production


SQL> SELECT count(*) FROM employees;

COUNT(*)

----------

107

SQL> exit

Disconnected from Oracle Database 10g Enterprise Edition Release10.2.0.2.0 - With the Partitioning, Oracle Label Security, OLAP and Data Mining options

e. On the Data Guard page, select the standby database and click Edit. f. Select Online in the Log Apply Services section. Click Apply. The “All changes

successfully applied.” message is displayed.g. Return to the Data Guard page and verify the status of Normal for your standby database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)h. Open a terminal window and telnet to the machine your standby database is on. Log in as

the oracle user with password of oracle. Invoke SQL*Plus. Connect as the HR user and attempt to query the HR.EMPLOYEES table as follows:SQL> SELECT count(*) FROM employees;

Sample output is as follows:[oracle@EDRSR4P1 oracle]$ sqlplus hr/hr



ERROR:

ORA-00604: error occurred at recursive SQL level 1

ORA-01219: database not open: queries allowed on fixed tables/views only

8. You have determined that the users will need to run reports on a regular basis and do not want to impact the production database. In addition, you would like to add a standby database to your configuration for additional data protection. Configure a second standby database that will be available for users to perform queries, summations, and reporting activities against at all times with the following specifications:Standby database unique and target name: <HOSTNAME>_SITE2Location: Create your standby database on the next highest student PC in your classroom. For example, if your host name is EDRSR8P1, create your standby database on EDRSR8P2. Note: Your instructor may modify this configuration. Use the naming conventions provided above to avoid confusion when selecting your databases in Grid Control. Record information on page A-18.

a. On the Data Guard page, click Add Standby Database.b. Select “Create a new logical standby database” and click Continue.c. Select “Perform a live backup of the primary database” and click Next.d. Accept the default location for the Backup Files Directory Location. Enter the Primary

Host Credentials if the fields are not already populated. Click Next.e. Accept the default instance name. Select the host for the Standby Database Location and

click Next.f. Select “Transfer files from the primary host backup files directory to a standby host

directory” and “Convert to OFA.” Click Next.g. Click Yes for the “The following files already exist and will be overwritten:

/u01/app/oracle/product/10.2.0/db_1/demo/schema/sales_history/sale1v3.dat; Click ‘Yes’to continue, or click ‘No’ then ‘Customize’ to make changes.” warning message.

h. Accept the Database Name. Change the Database Unique Name and Target Name to <HOSTNAME>_SITE2 as described above. Click Next.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)i. Review the information and click Finish.j. When the Data Guard page reappears, select “Real Time: 1 Minute Refresh” from the

View Data drop-down menu. You can also click the link in the Status column to review additional information.

9. Verify that the automatic gap detection and resolution feature is working properly in your configuration by simulating a loss of connectivity to your new standby database. Disable redo transport services to your standby database, switch the log on your primary database, and reenable redo transport services to your standby database.

a. Disable redo transport services to the logical standby database as follows:On the Data Guard page, select the logical standby database and click Edit. Select the Standby Role Properties page. Expand Show Advanced Properties. Select OFF in the Log Shipping drop-down menu. Click Apply.Return to the Databases target page.

b. Force three to five log switches on your primary database as follows:Select your primary database on the Database target page by clicking the link.Select Redo Log Groups on the Administration page for the primary database. Select Switch Logfile in the Actions drop-down menu and click Go. Repeat three to five times.Return to the Data Guard page and observe the difference in the current log number for the primary database and the last received log for the logical standby database.

c. Enable redo transport services to the logical standby database as follows:On the Data Guard page, select your logical standby database and click Edit. Select the Standby Role Properties page. Expand Show Advanced Properties. Select ON in the Log Shipping drop-down menu. Click Apply.

d. Verify that all redo has been applied to the logical standby database as follows:Return to the Data Guard page and observe that the logical standby database has received the redo log files from the primary database.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)10. Because the users want to use some tables in the new standby database to report against for

historical purposes, you need to configure SQL Apply so that certain DML statements are not executed against those tables on the logical standby database. You decide to test this feature first by creating a new table on the primary database as follows:CREATE TABLE hr.emp_name

AS SELECT first_name, last_name

FROM hr.employees

WHERE 1=2;

Define a filter that prevents SQL Apply from issuing DML statements against the HR.EMP_NAME table on the logical standby database. Insert a few rows into the HR.EMP_NAME table on the primary database and commit your changes. Force a log switch on the primary database and then verify that the new rows are not applied to your logical standby database.

a. Open a terminal window.b. Change to the labs directory.c. Invoke SQL*Plus and connect as hr/hr. Execute the lab_13_10_c.sql script in your labs directory to create the HR.EMP_NAME table as described. Maintain the SQL*Plus session for later steps.Note: If you receive an error regarding ORACLE_HOME, set it to: /u01/app/oracle/product/10.2.0/db_1

d. Configure SQL Apply on the logical standby database so that no DML statements are executed against the HR.EMP_NAME as follows:Navigate to the Data Guard page.Select the logical standby database and click Edit.Click Standby Role Properties.Expand Show Advanced Properties.Click Add in the Skip Table Entries section.Enter the following information in the specified fields:SQL Statement: DMLSchema: HRObject Name: EMP_NAMESelect “Always skip this statement type.”Click OK. Verify the information in the Skip Table Entries section and click Apply.A success message is displayed.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)e. In your SQL*Plus session, execute the lab_13_10_e.sql script in the labs directory to

insert two rows in the HR.EMP_NAME table as follows:INSERT INTO hr.emp_name

VALUES ('Don','Miller');

INSERT INTO hr.emp_name

VALUES ('Sally','Hebert');

COMMIT;

Exit from your SQL*Plus session.f. On your primary database, force a log switch as follows:

Access the Administration page for your primary database.Click Redo Log Groups.Select Switch logfile in the Actions drop-down menu and click Go.

g. Access your logical standby database and query the HR.EMP_NAME table to determine if any rows have been inserted into the table as follows:Open a terminal window and telnet to the machine your standby database is on. Log in as the oracle user with password of oracle. Invoke SQL*Plus for your logical standby database.Connect as hr/hr.Issue the following command:SELECT count(*) FROM emp_name;

There should be no rows in the emp_name table. Exit from SQL*Plus.Sample output is as follows:[oracle@EDRSR4P1 oracle]$ export ORACLE_SID=dg3

[oracle@EDRSR4P1 oracle]$ sqlplus hr/hr

SQL*Plus: Release 10.2.0.2.0 - Production on Thu Aug 24 07:00:58 2006


Connected to:



SQL> SELECT count(*) FROM emp_name;

COUNT(*)

----------

0

SQL> exit

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)11. You have been asked to create a view for the users to query on the logical standby database.

Create the view as follows:CREATE VIEW hr.emp_90_vw

AS SELECT *

FROM hr.employees

WHERE department_id=90;

a. Invoke SQL*Plus and connect to your logical standby database as the SYS user. Set the Data Guard guard to STANDBY so that you can create a view by issuing the following statement:ALTER DATABASE GUARD STANDBY;


[oracle@EDRSR4P1 oracle]$ sqlplus / as sysdba



Connected to:



SQL> ALTER DATABASE GUARD STANDBY;

Database altered.

SQL> exit

b. Connect to your logical standby database as HR, with HR as the password. Create a view on the HR.EMPLOYEES table as follows:CREATE VIEW emp_90_vw

AS SELECT *

FROM employees

WHERE department_id=90;

You can use the lab_13_11_b.sql script to create the view.Sample output follows:[oracle@EDRSR8P1 ~]$ cd labs

[oracle@EDRSR8P1 labs]$ sqlplus hr/hr



Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.2.0-Production

With the Partitioning, Oracle Label Security, OLAP and Data Mining

SQL> @lab_13_11_b.sql

View created.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)c. Connect to your logical standby database as SYS and set the Data Guard guard back to ALL as follows. Exit from SQL*Plus.ALTER DATABASE GUARD ALL;

Sample output is as follows:SQL> connect / as sysdba

Connected.

SQL> ALTER DATABASE GUARD ALL;

Database altered.

SQL> exit

12. You have experienced a failure on your primary database server. Fail over to your physical standby database.

a. On the Data Guard page, select your physical standby database and click Failover.On the Confirmation: Redirect page, click Yes to continue with the failover.Supply the database login information. Click Continue.Supply operating system credentials. Click Continue.On the Confirmation: Failover page, select Complete and click Yes.The Processing: Failover page is displayed.The Data Guard page is displayed after processing completes.

b. Force one or two log switches as follows:Click on the link for your new primary database.Select the Administration page and click Redo Log Groups.Select “Switch logfile” from the Actions drop-down menu and click Go. Repeat.Return to the Data Guard page.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y


Practice 13: Workshop Scenarios (continued)13. You have been able to restore the server on which your primary database was originally

located. Add your original primary database back into your Data Guard configuration as a physical standby database.

a. You can use Enterprise Manager to enable the physical standby database as follows:Access the Data Guard page. Your new physical standby database shows a status of “Database must be reinstated.” Click the “Database must be reinstated” link.On the Edit Standby Database Properties page, click Reinstate.Click Yes to confirm reinstating.The new physical standby database is reset and is now part of your configuration.Click Verify to verify your Data Guard configuration.Review the results of the verify and click OK to return to the Data Guard configuration.

14. Return to your original Data Guard configuration with your HOSTNAME_ORCL.oracle.com database as your primary database.

a. Perform a switchover operation by selecting your current physical standby database and clicking Switchover. Click Yes to confirm the switchover operation.

Ora

cle

Inte

rnal

& O

racl

e A

cade

my

Use

Onl

y

oracle database 10g: data guard administration acle...

Documents