Oracle® Data Guard

Broker

10g Release 2 (10.2)

B14230-02

March 2006

Oracle Data Guard Broker, 10g Release 2 (10.2)

B14230-02

Copyright © 1999, 2006, Oracle. All rights reserved.

Primary Author:  Viv Schupmann

Contributors:  Gary Allison, George Claborn, Sean Connolly, Jay Davison, Rhonda Day, Ray Dutcher, Mahesh Girkar, Michael Harvey, Nitin Karkhanis, Sadhana Kyathappala, Steve Lee, Jiangbin Luo, Venkat Maddali, Bob McGuirk, Jennifer Polk, Ashish Ray, Lawrence To, Stephen Vivian, Hongjie Yang

The Programs (which include both the software and documentation) contain proprietary information; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs, except to the extent required to obtain interoperability with other independently created software or as specified by law, is prohibited.

The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. This document is not warranted to be error-free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose.

If the Programs are delivered to the United States Government or anyone licensing or using the Programs on behalf of the United States Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software—Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and we disclaim liability for any damages caused by such use of the Programs.

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.

The Programs may provide links to Web sites and access to content, products, and services from third parties. Oracle is not responsible for the availability of, or any content provided on, third-party Web sites. You bear all risks associated with the use of such content. If you choose to purchase any products or services from a third party, the relationship is directly between you and the third party. Oracle is not responsible for: (a) the quality of third-party products or services; or (b) fulfilling any of the terms of the agreement with the third party, including delivery of products or services and warranty obligations related to purchased products or services. Oracle is not responsible for any loss or damage of any sort that you may incur from dealing with any third party.

Contents

List of Examples

List of Figures

List of Tables

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

What's New in Oracle Data Guard Broker?

1 Oracle Data Guard Broker Concepts

- 1.1 Overview of Oracle Data Guard and the Broker

- 1.1.1 Data Guard Configurations and Broker Configurations

- 1.1.2 Oracle Data Guard Broker

- 1.2 Benefits of Data Guard Broker

- 1.3 Data Guard Broker Management Model

- 1.4 Data Guard Broker Components

- 1.5 Data Guard Broker User Interfaces

- 1.5.1 Oracle Enterprise Manager

- 1.5.2 Data Guard Command-Line Interface (DGMGRL)

- 1.6 Data Guard Monitor

- 1.6.1 Data Guard Monitor (DMON) Process

- 1.6.2 Configuration Management

- 1.6.3 Database Property Management

2 Oracle Data Guard Installation

- 2.1 Oracle Data Guard Installation

- 2.2 Prerequisites for First Use

3 Managing Broker Configurations

- 3.1 Configuration Support

- 3.2 Setting Up the Broker Configuration Files

- 3.2.1 Renaming the Broker Configuration Files

- 3.2.2 Managing Broker Configuration Files in a Real Application Clusters Environment

- 3.2.2.1 Using Cluster File System (CFS) for Configuration Files

- 3.2.2.2 Using ASM Disk Groups for Configuration Files

- 3.2.2.3 Using Raw Devices for Configuration Files

- 3.3 Starting the Data Guard Broker

- 3.4 Management Cycle of a Broker Configuration

- 3.5 Enable and Disable Operations

- 3.6 Configuration Status

4 Managing Databases

- 4.1 Database Objects

- 4.2 Database States

- 4.2.1 Database State Transitions

- 4.3 Database Properties

- 4.3.1 Monitorable (Read-Only) Properties

- 4.3.2 Configurable (Changeable) Database Properties

- 4.4 Managing Redo Transport Services

- 4.4.1 Managing Redo Transport Services for Data Protection Modes

- 4.4.2 Turning On and Off Redo Transport Services

- 4.4.3 Specifying Locations for Archived Redo Log Files

- 4.4.4 Setting a Dependent Standby Database

- 4.4.5 Other Redo Transport Settings

- 4.4.6 Managing Connections to the Standby Databases for Redo Transport Services

- 4.4.7 Redo Transport Services in a RAC Database Environment

- 4.5 Managing Log Apply Services

- 4.5.1 Managing Delayed Apply

- 4.5.2 Managing Parallel Apply with Redo Apply

- 4.5.3 Allocating Resources to SQL Apply

- 4.5.4 Managing SQL Apply Filtering

- 4.5.5 Managing SQL Apply Error Handling

- 4.5.6 Managing the DBA_LOGSTDBY_EVENTS Table

- 4.5.7 Log Apply Services in a RAC Database Environment

- 4.5.7.1 Selecting the Apply Instance

- 4.5.7.2 Apply Instance Failover

- 4.6 Managing Data Protection Modes

- 4.6.1 Setting the Protection Mode for Your Configuration

- 4.6.2 How the Protection Modes Influence Broker Operations

- 4.6.2.1 Upgrading or Downgrading the Current Protection Mode

- 4.6.2.2 Switchover Operations

- 4.6.2.3 Failover Operations

- 4.6.2.4 Disable and Enable Operations

- 4.6.2.5 Requirements For Removing a Database from the Configuration

- 4.6.2.6 Requirements On Other Operations

- 4.7 Database Status

5 Switchover and Failover Operations

- 5.1 Overview of Switchover and Failover in a Broker Environment

- 5.2 Choosing a Target Standby Database

- 5.2.1 Choosing a Target Standby Database for Switchover

- 5.2.2 Choosing a Target Standby Database for Failover

- 5.3 Switchover

- 5.3.1 Before You Perform a Switchover Operation

- 5.3.2 Starting a Switchover

- 5.3.3 How the Broker Performs a Switchover

- 5.4 Manual Failover

- 5.4.1 Complete and Immediate Manual Failovers

- 5.4.2 Performing a Manual Failover Operation

- 5.4.2.1 How the Broker Performs a Complete Failover Operation

- 5.4.2.2 How the Broker Performs an Immediate Failover Operation

- 5.4.3 Reenabling Disabled Databases After Failover or Switchover

- 5.4.3.1 How to Reinstate a Database

- 5.4.3.2 How to Re-create and Reenable a Disabled Database

- 5.5 Fast-Start Failover

- 5.5.1 Prerequisites for Enabling Fast-Start Failover

- 5.5.2 Enabling Fast-Start Failover

- 5.5.2.1 What Happens When Fast-Start Failover and the Observer Are Running?

- 5.5.2.2 Restrictions When Fast-Start Failover is Enabled

- 5.5.2.3 Shutting Down the Primary Database When Fast-Start Failover Is Enabled

- 5.5.2.4 Performing Manual Role Changes When Fast-Start Failover Is Enabled

- 5.5.3 Viewing Fast-Start Failover Configuration Statistics and Status

- 5.5.4 Disabling Fast-Start Failover

- 5.5.5 Performance Considerations for Fast-Start Failover

- 5.5.6 Managing the Observer

- 5.5.6.1 Installing and Starting the Observer

- 5.5.6.2 Viewing Information About the Observer

- 5.5.6.3 What Happens if the Observer Fails?

- 5.5.6.4 Stopping the Observer

- 5.5.6.5 Moving the Observer to Another Computer

- 5.5.6.6 How the Observer Maintains Fast-Start Failover Configuration Information

- 5.5.7 Reinstating the Former Primary Database in the Broker Configuration

- 5.5.7.1 Requirements

- 5.5.7.2 Restrictions on Reinstatement

- 5.5.7.3 How the Broker Handles a Failed Reinstatement

- 5.5.8 Shutting Down Databases In a Fast-Start Failover Environment

6 Scenarios Using Oracle Enterprise Manager

- 6.1 Scenario 1: Accessing the Data Guard User Interface

- 6.2 Scenario 2: Creating a Configuration or Adding an Additional Standby Database

- 6.3 Scenario 3: Adding an Existing RAC Standby Database

- 6.4 Scenario 4: Enabling Fast-Start Failover and the Observer

- 6.5 Scenario 5: Performing Routine Maintenance

- 6.5.1 Changing the State of a Database

- 6.5.2 Changing the Properties of a Database

- 6.5.3 Changing the Database Protection Mode

- 6.6 Scenario 6: Performing a Switchover Operation

- 6.7 Scenario 7: Invoking a Failover Manually

- 6.8 Scenario 8: Monitoring a Data Guard Configuration

- 6.8.1 Verifying a Broker Configuration

- 6.8.2 Viewing Log File Details

- 6.8.3 Monitoring Configuration Performance

- 6.9 Scenario 9: Using Metrics

- 6.9.1 Understanding the Data Guard Metrics

- 6.9.1.1 Fast-Start Failover Metrics

- 6.9.1.2 Data Guard Performance Metrics

- 6.9.1.3 Data Guard Status

- 6.9.2 Managing Data Guard Metrics

- 6.10 Scenario 10: Removing a Standby Database and Configuration

- 6.10.1 Remove a Standby Database

- 6.10.2 Remove the Data Guard Configuration

7 Scenarios Using the DGMGRL Command-Line Interface

- 7.1 Prerequisites for Getting Started

- 7.2 Scenario 1: Creating a Configuration

- 7.3 Scenario 2: Setting Database Properties

- 7.4 Scenario 3: Enabling the Configuration and Databases

- 7.5 Scenario 4: Setting the Configuration Protection Mode

- 7.6 Scenario 5: Enabling Fast-Start Failover and the Observer

- 7.7 Scenario 6: Performing Routine Management Tasks

- 7.7.1 Changing Properties and States

- 7.7.1.1 Alter a Database Property

- 7.7.1.2 Alter the State of a Standby Database

- 7.7.1.3 Alter the State of a Primary Database

- 7.7.2 Disabling the Configuration and Databases

- 7.7.2.1 Disable a Configuration

- 7.7.2.2 Disable a Standby Database

- 7.7.3 Removing the Configuration or a Standby Database

- 7.8 Scenario 7: Performing a Switchover Operation

- 7.9 Scenario 8: Performing a Manual Failover Operation

- 7.10 Scenario 9: Monitoring a Data Guard Configuration

8 Data Guard Command-Line Interface Reference

- 8.1 Starting the Data Guard Command-Line Interface

- 8.1.1 DGMGRL Optional Parameters

- 8.1.2 DGMGRL Command Format and Parameters

- 8.1.3 DGMGRL Command Usage Notes

- 8.2 Stopping the Data Guard Command-Line Interface

- ADD DATABASE

- CONNECT

- CREATE CONFIGURATION

- DISABLE CONFIGURATION

- DISABLE DATABASE

- DISABLE FAST_START FAILOVER

- EDIT CONFIGURATION (Property)

- EDIT CONFIGURATION (Protection Mode)

- EDIT DATABASE (Property)

- EDIT DATABASE (Rename)

- EDIT DATABASE (State)

- EDIT INSTANCE (AUTO PFILE)

- EDIT INSTANCE (Property)

- ENABLE CONFIGURATION

- ENABLE DATABASE

- ENABLE FAST_START FAILOVER

- EXIT

- FAILOVER

- HELP

- QUIT

- REINSTATE DATABASE

- REMOVE CONFIGURATION

- REMOVE DATABASE

- REMOVE INSTANCE

- SHOW CONFIGURATION

- SHOW DATABASE

- SHOW INSTANCE

- SHUTDOWN

- START OBSERVER

- STARTUP

- STOP OBSERVER

- SWITCHOVER

9 Database Properties

- 9.1 Monitorable (Read-Only) Database Properties

- 9.1.1 InconsistentLogXptProps (Inconsistent Redo Transport Properties)

- 9.1.2 InconsistentProperties (Inconsistent Database Properties)

- 9.1.3 LogXptStatus (Redo Transport Status)

- 9.1.4 LsbyFailedTxnInfo (Logical Standby Failed Transaction Information)

- 9.1.5 LsbyParameters (Logical Standby Parameters)

- 9.1.6 LsbySkipTable (Logical Standby Skip Table)

- 9.1.7 LsbySkipTxnTable (SQL Apply Skip Transaction Table)

- 9.1.8 RecvQEntries (Receive Queue Entries)

- 9.1.9 SendQEntries (Send Queue Entries)

- 9.1.10 StatusReport (Status Report)

- 9.1.11 TopWaitEvents

- 9.2 Configurable Database Properties

- 9.2.1 AlternateLocation

- 9.2.2 ApplyInstanceTimeout

- 9.2.3 ApplyParallel

- 9.2.4 ArchiveLagTarget

- 9.2.5 Binding

- 9.2.6 DbFileNameConvert

- 9.2.7 DelayMins

- 9.2.8 Dependency

- 9.2.9 FastStartFailoverTarget

- 9.2.10 FastStartFailoverThreshold

- 9.2.11 HostName

- 9.2.12 InitialConnectIdentifier

- 9.2.13 LocalListenerAddress

- 9.2.14 LogArchiveFormat

- 9.2.15 LogArchiveMaxProcesses

- 9.2.16 LogArchiveMinSucceedDest

- 9.2.17 LogArchiveTrace

- 9.2.18 LogFileNameConvert

- 9.2.19 LogShipping

- 9.2.20 LogXptMode

- 9.2.21 LsbyASkipCfgPr

- 9.2.22 LsbyASkipErrorCfgPr

- 9.2.23 LsbyASkipTxnCfgPr

- 9.2.24 LsbyDSkipCfgPr

- 9.2.25 LsbyDSkipErrorCfgPr

- 9.2.26 LsbyDSkipTxnCfgPr

- 9.2.27 LsbyMaxEventsRecorded

- 9.2.28 LsbyMaxSga

- 9.2.29 LsbyMaxServers

- 9.2.30 LsbyRecordAppliedDdl

- 9.2.31 LsbyRecordSkipDdl

- 9.2.32 LsbyRecordSkipErrors

- 9.2.33 LsbyTxnConsistency

- 9.2.34 MaxConnections

- 9.2.35 MaxFailure

- 9.2.36 NetTimeout

- 9.2.37 PreferredApplyInstance

- 9.2.38 ReopenSecs

- 9.2.39 SidName

- 9.2.40 StandbyArchiveLocation

- 9.2.41 StandbyFileManagement

10 Troubleshooting Data Guard

- 10.1 Sources of Diagnostic Information

- 10.2 General Problems and Solutions

- 10.2.1 ORA-16596: Object Not Part of the Data Guard Broker Configuration

- 10.2.2 Redo Accumulating on the Primary Is Not Sent to Some Standby Databases

- 10.2.3 Many Log Files Are Received on a Standby Database But Not Applied

- 10.2.4 The Request Timed Out or Enterprise Manager Performance Is Sluggish

- 10.2.5 The Primary Database is Flashed Back

- 10.3 Troubleshooting Problems During a Switchover Operation

- 10.4 Troubleshooting Problems During a Failover Operation

- 10.5 Troubleshooting Problems with the Observer

- 10.5.1 Problems Starting the Observer

- 10.5.2 Problems Because the Observer Has Stopped

- 10.5.3 Capturing Observer Actions in the Observer Log File

A Changed and Deprecated Features

- A.1 Changed Features

- A.1.1 General Features That Changed

- A.1.1.1 Changed Features in Release 10.2

- A.1.1.2 Changed Features in Release 10.1

- A.1.2 Changed Properties

- A.1.2.1 Changed Properties in Release 10.2

- A.1.2.2 Changed Properties in Release 10.1

- A.1.3 Changed State Names in Release 10.1

- A.1.4 Changed DGMGRL Features in Release 10.2

- A.1.5 Changed DGMGRL Features in Release 10.1

- A.1.6 Changed Enterprise Manager Features in Release 10.1

- A.2 Deprecated and Obsolete Features

- A.2.1 Deprecated and Obsolete Features in Release 10.2

- A.2.1.1 Deprecated and Obsolete Properties in Release 10.2

- A.2.2 Deprecated and Obsolete Features in Release 10.1

- A.2.2.1 Deprecated and Obsolete Properties in Release 10.1

- A.2.2.2 Deprecated and Obsolete DGMGRL Commands in Release 10.1

- A.2.2.3 Obsolete Enterprise Manager Feature in Release 10.1

B Data Guard Broker Upgrading and Downgrading

- B.1 Upgrade from Release 9.0.n to Release 10.n

- B.2 Upgrade from Release 9.2.0 to Release 10.n

- B.3 Upgrade from Release 10.1 to Release 10.2

- B.4 Downgrade from Release 10.2

Glossary

Index

List of Examples

- 4-1 Using the SHOW DATABASE VERBOSE Command to Display Properties

- 4-2 Turn Off Redo Transport Services to All Standby Databases

- 4-3 Turn Off Redo Transport Services to a Specific Standby Database

- 7-1 Connecting to the Primary Database on the Local System

- 7-2 Connecting to the Primary Database on a Remote System

- 7-3 Altering a Database Property

- 7-4 Altering a Standby Database State

- 7-5 Altering a Primary Database State

- 7-6 Disabling the Configuration and Primary Database

- 7-7 Disabling a Standby Database

List of Figures

- 1-1 Relationship of Objects Managed by the Data Guard Broker

- 1-2 Oracle Data Guard Broker

- 1-3 Data Guard Overview Page in Oracle Enterprise Manager

- 1-4 Databases With Broker (DMON) Processes

- 3-1 Oracle Data Guard Broker Configuration

- 3-2 Broker Configuration Setup in a CFS Area

- 3-3 Broker Configuration Setup with ASM

- 3-4 Broker Configuration Setup with Raw Devices

- 3-5 Life Cycle of a Broker Configuration and Its Databases

- 4-1 Database State Transition Diagrams

- 5-1 Relationship of Primary and Standby Databases and the Observer

- 5-2 The Observer in the Fast-Start Failover Environment

- 6-1 Create a Broker Configuration

- 6-2 Data Guard Overview Page

- 6-3 Add Standby Database Wizard - Introductory Page

- 6-4 Add Standby Database Wizard - Backup Type (Logical Standby Database)

- 6-5 Add Standby Database Wizard - Backup Type (Logical Standby Database)

- 6-6 Add Standby Database Wizard - Backup Options

- 6-7 Add Standby Database Wizard - Database Location

- 6-8 Add Standby Database Wizard - File Locations

- 6-9 Add Standby Database Wizard - Configuration

- 6-10 Add Standby Database Wizard - Review

- 6-11 Add Standby Database Wizard - Processing

- 6-12 Data Guard Overview Page - Creation in Progress

- 6-13 Adding an Existing RAC Standby Database to the Data Guard Configuration

- 6-14 Select an Existing Standby Database

- 6-15 Add Standby Database: Standby Configuration

- 6-16 Add Standby Database: Review

- 6-17 Fast-Start Failover Wizard: Configure

- 6-18 Fast-Start Failover Wizard: Set Observer

- 6-19 Fast-Start Failover Wizard: Enable Flashback Logging

- 6-20 Fast-Start Failover Wizard: Confirmation

- 6-21 Fast-Start Failover Wizard: Progress

- 6-22 Fast-Start Failover Is Successfully Enabled

- 6-23 Reinstating the Former Primary Database After a Fast-Start Failover

- 6-24 Alert Log Errors Page Showing That Fast-Start Failover Occurred

- 6-25 Changing the State or Properties of a Database

- 6-26 Standby Role Properties

- 6-27 Standby Advanced Properties

- 6-28 Common Properties

- 6-29 Change Protection Mode Page

- 6-30 Change Protection Mode - Standby Databases and Online Redo Log Files

- 6-31 Change Protection Mode - Process

- 6-32 Protection Mode Successfully Changed

- 6-33 Switchover Operation

- 6-34 Processing Page During Switchover

- 6-35 New Primary Database After Switchover

- 6-36 Data Guard Overview Page Showing ORA-16625 Error

- 6-37 Failover Confirmation Page

- 6-38 Failover Progress Page

- 6-39 Data Guard Overview Page After a Failover Operation Completes

- 6-40 Data Guard Overview Page Showing Observer Error

- 6-41 Verifying the Configuration

- 6-42 Results of the Verify Command

- 6-43 Viewing Log File Details

- 6-44 Performance Page

- 6-45 Data Guard Metrics

- 6-46 Alert Log Errors Page Showing the Observer Has Stopped

- 6-47 Removing a Standby Database

- 6-48 Removing a Data Guard Broker Configuration

List of Tables

- 1-1 Configuration Management With and Without the Broker

- 1-2 DGMGRL Commands

- 4-1 Database States and Descriptions

- 4-2 Data Guard Protection Modes and Requirements

- 5-1 Reenabling Disabled Databases After Failover or Switchover

- 5-2 FS_FAILOVER_STATUS Column of the V$DATABASE View

- 5-3 FS_FAILOVER_OBSERVER_PRESENT Column of the V$DATABASE View

- 6-1 Log File Details Page

- 8-1 Summary of DGMGRL Commands

- 9-1 Configurable Properties

- A-1 Changed Properties in Release 10.2

- A-2 Changed Properties in Release 10.1

- A-3 State Name Changes

- A-4 Deprecated Properties

- A-5 Deprecated Properties

- A-6 Deprecated Commands or Keywords

Preface

This document provides information about Oracle Data Guard Broker, a management and monitoring interface that helps you configure, monitor, and control an Oracle Data Guard broker configuration.

Audience

Oracle Data Guard Broker is intended for database administrators (DBAs) and system administrators who want to use the Oracle Data Guard broker to automate many of the tasks involved in configuring and monitoring an Oracle Data Guard configuration.

The discussions herein assume that readers are already familiar with Oracle Data Guard, Oracle Enterprise Manager, Oracle Real Application Clusters, and the network services provided by Oracle Net Services.

Documentation Accessibility

Our goal is to make Oracle products, services, and supporting documentation accessible, with good usability, to the disabled community. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at

http://www.oracle.com/accessibility/

Accessibility of Code Examples in Documentation

Screen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.

Accessibility of Links to External Web Sites in Documentation

This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.

TTY Access to Oracle Support Services

Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services within the United States of America 24 hours a day, seven days a week. For TTY support, call 800.446.2398.

Related Documents

Refer to the following documentation for more information about Oracle Data Guard:

- Oracle Data Guard Concepts and Administration.

- Oracle release notes specific to your operating system.

- Oracle installation guide specific to your operating system.

- For more information about managing Oracle Data Guard through Oracle Enterprise Manager, see the online Help available with this graphical user interface. To access the online Help topics, click Help on the menu bar in Enterprise Manager.

Refer to the following documentation for information about related products:

- Oracle Database Concepts

- Oracle Database Net Services Administrator's Guide

- Oracle Enterprise Manager product documentation set

- Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide

- Oracle Call Interface Programmer's Guide for more information about Oracle Instant Client

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

What's New in Oracle Data Guard Broker?

This preface describes the new features added to Oracle Data Guard broker in 10g Release 2 (10.2) and provides links to additional information.

This release provides the following new features:

- Fast-start failover

Fast-start failover provides the ability to automatically, quickly, and reliably fail over to a designated, synchronized standby database in the event of loss of the primary database, without requiring that you perform any manual steps to invoke the failover.

This new capability allows you to maintain uptime transparently and increase the degree of high availability, as well the robustness of disaster recovery. Plus, there is less need for manual intervention, thereby reducing management costs.

See Also:
Section 5.5, "Fast-Start Failover"

- Reinstatement of the primary database to a standby database after a failover

After a fast-start failover occurs, the old primary database will automatically reconfigure itself as a new standby database upon reconnection to the configuration. Automatic reinstatement restores disaster protection in the configuration easily, without complex manual steps, improving the robustness of the disaster-recovery features of Data Guard, as well as improving Data Guard manageability.

See Also:
Section 5.5.7, "Reinstating the Former Primary Database in the Broker Configuration"

- Data Guard enhancements in Oracle Enterprise Manager

Enhancements in Oracle Enterprise Manager include the following items:

Note:
Data Guard features are not available in Enterprise Manager Database Control. You must install Enterprise Manager Grid Control to access Data Guard functionality.

See Also:
The Enterprise Manager online help, which is available from any Enterprise Manager page. Click Help on an Enterprise Manager page to display a context-sensitive help topic that contains information about the features available on that page.

- Compression of backups during standby creation

During the process of creating a standby database, Enterprise Manager has the option to perform an online backup of the primary database. This feature provides the ability to create the backup in a compressed manner, it saves disk storage, and it is especially useful for large-sized databases.

- Support for flash recovery area for physical standby databases

Flash Recovery Areas can be automatically configured for physical standby databases during their creation through Enterprise Manager. Archived log files will be automatically managed by Oracle in the flash recovery area of the physical standby database, leading to fewer manual operations and reduced management costs when maintaining a Data Guard configuration.

- Support of standby databases in an Oracle Managed Files (OMF) or Automatic Storage Management (ASM) configuration

Standby databases may now be created through Enterprise Manager in an ASM/OMF configuration. This feature provides all the benefits of ASM/OMF to both the primary and standby databases. For example, the storage management issues related to the standby database are automatically handled by Oracle, leading to fewer manual operations and reduced management costs.

- New and improved apply statistics

Performance statistics showing redo transfer rates and log apply rates have been improved and enhanced.

- Status alerts for non-broker configurations

Ability to scan archiving information and other sources on the primary database to flag problems and error situations in the Data Guard configuration, even though the broker is not enabled. This feature increases the flexibility of Enterprise Manager usage as an effective monitoring interface for all Data Guard configurations.

- Test redo generator

Enterprise Manager now ships with a redo generation test application that is easily accessible through the browser-based interface, with which redo data can be generated in the primary database and automatically transmitted to standby databases by Data Guard. This feature helps you test and verify the Data Guard configuration. For example, you can use the application to test the configuration before deploying it in production. Similarly, troubleshooting may also be done in the production configuration using this application.

- Broker configuration files can reside on an ASM disk group

The broker's configuration files can reside on an ASM disk group. Because these configuration files must be explicitly named by the user, the configuration files are not Oracle Managed Files (OMF). Now, any storage management issues related to the configuration files will be automatically handled by Oracle, leading to fewer manual operations and reduced management costs.

See Also:
Section 3.2.2.2, "Using ASM Disk Groups for Configuration Files"

- DelayMins property

Setting the DelayMins property is now the preferred method for indicating whether or not you want to delay the application of redo data to the standby database.

See Also:
Section A.1.2, "Changed Properties" for complete information

- New Data Guard command-line interface (DGMGRL) commands include:

- ENABLE FAST_START FAILOVER

- DISABLE FAST_START FAILOVER

- START OBSERVER

- STOP OBSERVER

- REINSTATE DATABASE

See Also:
Chapter 8, "Data Guard Command-Line Interface Reference"

- New database properties include:

- FastStartFailoverTarget

- FastStartFailoverThreshold

- MaxConnections

See Also:
Chapter 9, "Database Properties"

- New configuration properties include:

- FastStartFailoverThreshold

See Also:
Chapter 9, "Database Properties"

- LogArchiveMaxProcesses property range of valid values is now from 1 to 30 (was from 1 to 10)

See Also:
Section 9.2.15, "LogArchiveMaxProcesses"

- LsbyTxnConsistency property now imports the value of PRESERVE_COMMIT_ORDER from SYSTEM.LOGSTDBY$PARAMETERS instead of TRANSACTION_CONSISTENCY.

See Also:
Section 9.2.33, "LsbyTxnConsistency"

1 Oracle Data Guard Broker Concepts

This chapter describes the Oracle Data Guard broker, its architecture and components, and how it automates the creation, control, and monitoring of a Data Guard configuration.

The following sections introduce Data Guard broker terminology and concepts:

- Section 1.1, "Overview of Oracle Data Guard and the Broker"

- Section 1.2, "Benefits of Data Guard Broker"

- Section 1.3, "Data Guard Broker Management Model"

- Section 1.4, "Data Guard Broker Components"

- Section 1.5, "Data Guard Broker User Interfaces"

- Section 1.6, "Data Guard Monitor"

See Oracle Data Guard Concepts and Administration for the definition of a Data Guard configuration and for complete information about Oracle Data Guard concepts and terminology.

1.1 Overview of Oracle Data Guard and the Broker

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the primary database. If the primary database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, thus minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, recovery, and cluster techniques, as well as the Flashback Database feature to provide a high level of data protection and data availability.

1.1.1 Data Guard Configurations and Broker Configurations

A Data Guard configuration consists of one primary database and up to nine standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located if they can communicate with each other. For example, you can have a standby database on the same system as the primary database, along with two standby databases on another system.

The Data Guard broker logically groups these primary and standby databases into a broker configuration that allows the broker to manage and monitor them together as an integrated unit. You can manage a broker configuration using either the Oracle Enterprise Manager graphical user interface or the Data Guard command-line interface.

1.1.2 Oracle Data Guard Broker

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

- Creating Data Guard configurations that incorporate a primary database, a new or existing (physical or logical) standby database, redo transport services, and log apply services, where any of the databases could be Real Application Clusters (RAC) databases.

- Adding additional new or existing (physical or logical, RAC or non-RAC) standby databases to an existing Data Guard configuration, for a total of one primary database, and from 1 to 9 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.

- Managing the protection mode for the broker configuration.

- Invoking switchover or failover with a single command to initiate and control complex role changes across all databases in the configuration.

- Configuring failover to occur automatically upon loss of the primary database, increasing availability without manual intervention.

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

You can perform all management operations locally or remotely through the broker's easy-to-use interfaces: the Data Guard management pages in Oracle Enterprise Manager, which is the broker's graphical user interface (GUI), and the Data Guard command-line interface called DGMGRL.

These interfaces simplify the configuration and management of a Data Guard configuration. Table 1-1 provides a comparison of configuration management using the broker's interfaces and using SQL*Plus.

Table 1-1 Configuration Management With and Without the Broker

With the Broker

Without the Broker

General

Provides primary and standby database management as one unified configuration.

You must manage the primary and standby databases separately.

Standby Database Creation

Provides the Enterprise Manager wizards that automate and simplify the steps required to create a configuration with an Oracle database on each site, including creating the standby control file, online redo log files, datafiles, and server parameter files.

You must manually:

- Copy the database files to the standby database.

- Create a control file on the standby database.

- Create server parameter or initialization parameter files on the standby database.

Configuration and Management

Enables you to configure and manage multiple databases from a single location and automatically unifies all of the databases in the broker configuration.

You must manually:

- Set up redo transport services and log apply services on each database in the configuration.

- Manage the primary database and standby databases individually.

Control

- Automatically set up redo transport services and log apply services. Simplify management of these services, especially in a RAC environment.

- Simplifies switchovers and failovers by allowing you to invoke them through a single command.

- Automates failover by allowing the broker to determine if failover is necessary and initiate failover to a specified target standby database, with no need for DBA intervention and with no loss of data.

- Integrates Cluster Ready Services (CRS)Foot 1  and instance management over database role transitions.

- Provides mouse-driven database state changes and a unified presentation of configuration and database status.

- Provides mouse-driven property changes.

You must manually:

- Use multiple SQL*Plus statements to manage the database.

- Coordinate sequences of multiple commands across multiple database sites to execute switchover and failover operations.

- Coordinate sequences of multiple commands to manage services and instances during role transitions.

Monitoring

- Provides continuous monitoring of the configuration health, database health, and other runtime parameters.

- Provides a unified updated status and detailed reports.

- Provides integration with Oracle Enterprise Manager events.

You must manually:

- Monitor the status and runtime parameters using fixed views on each database—there is no unified view of status for all of the databases in the configuration.

- Provide a custom method for monitoring Oracle Enterprise Manager events.

Footnote 1 Cluster Ready Services (CRS) are part of Oracle Clusterware.

1.2 Benefits of Data Guard Broker

The broker's interfaces improve usability and centralize management and monitoring of the Data Guard configuration. Available as a feature of the Enterprise Edition and Personal Edition of the Oracle database, the broker is also integrated with the Oracle database and Oracle Enterprise Manager. These broker attributes result in the following benefits:

Disaster protection:  By automating many of the manual 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. Access is possible through a client to any system in the Data Guard configuration, eliminating any single point of failure. If the primary database fails, the broker automates the process for any one of the standby databases to replace the primary database and take over production processing. The database availability that Data Guard provides makes it easier to protect your data.

Higher availability and scalability with Real Application Clusters (RAC) Databases: While Oracle Data Guard broker enhances disaster protection by maintaining transactionally consistent copies of the primary database, Data Guard, configured with Oracle high availability solutions such as Real Application Clusters (RAC) databases, further enhances the availability and scalability of any given copy of that database. The intrasite high availability of a RAC database complements the intersite protection that is provided by Data Guard broker.

Consider that you have a cluster system hosting a primary RAC database comprised of multiple instances sharing access to that database. Further consider that an unplanned failure has occurred. From a Data Guard broker perspective, the primary database remains available as long as at least one instance of the clustered database continues to be available for transporting redo data to the standby databases. Oracle Clusterware manages the availability of instances of a RAC database. Cluster Ready Services (CRS), a subset of code that is a part of Oracle Clusterware, works to rapidly recover failed instances to keep the primary database available. If CRS is unable to recover a failed instance, the broker continues to run automatically with one less instance. If the last instance of the primary database fails, the broker provides a way to fail over to a specified standby database.

The broker is integrated with CRS so that database role changes occur smoothly and seamlessly. This is especially apparent in the case of a planned role switchover (for example, when a physical standby database is directed to take over the primary role while the former primary database assumes the role of standby). The broker and CRS work together to temporarily suspend service availability on the primary database, accomplish the actual role change for both databases during which CRS works with the broker to properly restart the instances as necessary, then to resume service availability on the new primary database. The broker manages the underlying Data Guard configuration and its database roles while CRS manages service availability that depends upon those roles. Applications that rely on CRS for managing service availability will see only a temporary suspension of service as the role change occurs in the Data Guard configuration.

Note that, while CRS enhances availability of a given copy of the RAC database, the broker enhances availability of the sites and databases across multiple geographically dispersed locations, hence providing disaster protection. Together, the broker and Oracle Clusterware provide a strong foundation for Oracle's high-availability architecture.

See Also:
Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for information about Oracle Clusterware and CRS

Automated creation of a Data Guard configuration: The broker helps you to logically define and create a Data Guard configuration consisting of a primary database and (physical or logical, RAC or non-RAC) standby databases. The broker automatically communicates between the databases in a Data Guard configuration using Oracle Net Services. The databases can be local or remote, connected by a LAN or geographically dispersed over a WAN.

Oracle Enterprise Manager provides a wizard that automates the complex tasks involved in creating a broker configuration, including:

- Adding an existing standby database, or a new standby database created from existing backups taken through Enterprise Manager

- Configuring the standby control file, server parameter file, and datafiles

- Initializing communication with the standby databases

- Creating standby redo log files

- Enabling Flashback Database if you plan to use fast-start failover

Although DGMGRL cannot automatically create a new standby database, you can use DGMGRL commands to configure and monitor an existing standby database, including those created using Enterprise Manager.

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 new or existing, physical or logical standby databases to each Data Guard configuration. Oracle Enterprise Manager provides an Add Standby Database wizard to guide you through the process of adding more databases. It also makes all Oracle Net Services configuration changes necessary to support redo transport services and log apply services across the configuration.

Simplified, centralized, and extended management: You can issue commands to manage many aspects of the broker configuration. These include:

- Simplify the management of all components of the configuration, including the primary and standby databases, redo transport services, and log apply services.

- Coordinate database state transitions and update database properties dynamically with the broker recording the changes in a broker configuration file that includes profiles of all the databases in the configuration. The broker propagates the changes to all databases in the configuration and their server parameter files.

- Simplify the control of the configuration protection modes (to maximize protection, to maximize availability, or to maximize performance).

- Invoke the Enterprise Manager verify operation to ensure that redo transport services and log apply services are configured and functioning properly.

Simplified switchover and failover operations: The broker simplifies switchovers and failovers by allowing you to invoke them using a single key click in Oracle Enterprise Manager or a single command at the DGMGRL command-line interface. (referred to in this documentation as manual failover). For lights-out administration, you can enable fast-start failover to allow the broker to determine if a failover is necessary and initiate the failover to a pre-specified target standby database automatically, with no need for DBA intervention and with no loss of data.

Fast-start failover allows you to increase availability with less need for manual intervention, thereby reducing management costs. Manual failover gives you control over exactly when a failover occurs and to which target standby database. Regardless of the method you choose, the broker coordinates the role transition on all databases in the configuration.

Only one command is required to initiate complex role changes for switchover or failover operations across all databases in the configuration. The broker automates switchover and failover to a specified standby database in the broker configuration. Enterprise Manager enables you to select a new primary database from a set of viable standby databases (enabled and online, with normal status). The DGMGRL SWITCHOVER and FAILOVER commands only require you to specify the target standby database before automatically initiating and completing the many steps in switchover or failover operations across the multiple databases in the configuration.

Built-in monitoring and alert and control mechanisms: The broker provides built-in validation that monitors the health of all of the databases in the configuration. From any system in the configuration connected to any database, you can capture diagnostic information and detect obvious and subtle problems quickly with centralized monitoring, testing, and performance tools. Both Enterprise Manager and DGMGRL retrieve a complete configuration view of the progress of redo transport services on the primary database and the progress of Redo Apply or SQL Apply on the standby database.

The ability to monitor local and remote databases and respond to events is significantly enhanced by the broker's health check mechanism and tight integration with the Oracle Enterprise Manager event management system.

Transparent to application: Use of the broker is possible for any database because the broker works transparently with applications; no application code changes are required to accommodate a configuration that you manage with the broker.

See Also:
Oracle Data Guard Concepts and Administration for a complete description of the discrete steps that comprise the creation of standby databases and the other monitoring and control operations that have been automated or simplified by the broker

1.3 Data Guard Broker Management Model

The broker simplifies the management of a Data Guard environment by performing operations on the following logical objects:

- Configuration of databases

- A single database

The broker supports one or more Data Guard configurations, each of which includes a profile for the primary database and each standby database. A supported broker configuration consists of:

- A configuration object, which is a named collection of database profiles. A database profile is a description of a database object including its current state, current status, and properties. The configuration object profiles one primary database and its standby databases that can include a mix of both physical and logical standby databases. The databases of a given configuration are typically distributed across multiple host systems.

- Database objects, corresponding to primary or standby databases. The broker uses a database object's profile to manage and control the state of a single database on a given system. The database object may be comprised of one or more instance objects if this is a RAC database.

- Instance objects. The broker treats a database as a collection of one or more named instances. The broker automatically discovers the instances and associates them with their database.

Figure 1-1 shows the relationship of these objects.

Figure 1-1 Relationship of Objects Managed by the Data Guard Broker

See also:
Chapter 3, Chapter 4, and Chapter 5 for more information about managing configuration and database objects

1.4 Data Guard Broker Components

The Oracle Data Guard broker consists of the following components:

- Oracle Enterprise Manager

- Data Guard Command-Line Interface (DGMGRL)

- Data Guard Monitor

Oracle Enterprise Manager and the Data Guard command-line interface (DGMGRL) are the broker client interfaces that help you define and manage a configuration consisting of a collection of primary and standby databases. DGMGRL also includes commands to create an observer, a process that facilitates fast-start failover. Section 1.5 describes these interfaces in more detail.

The Data Guard monitor is the broker server-side component that is integrated with the Oracle database. Data Guard monitor is composed of the DMON process and broker configuration files that allow you to control the databases of that configuration, modify their behavior at runtime, monitor the overall health of the configuration, and provide notification of other operational characteristics. Section 1.6 describes the Data Guard monitor in more detail.

Figure 1-2 shows these components of the broker.

Figure 1-2 Oracle Data Guard Broker

1.5 Data Guard Broker User Interfaces

You can use either of the broker's user interfaces to create a broker configuration and to control and monitor the configuration. The following sections describe the broker's user interfaces:

- Oracle Enterprise Manager

- Data Guard Command-Line Interface (DGMGRL)

1.5.1 Oracle Enterprise Manager

Oracle Enterprise Manager works with the Data Guard monitor to automate and simplify the management of a Data Guard configuration.

With Enterprise Manager, the complex operations of creating and managing standby databases are simplified through Data Guard management pages and wizards, including:

- An Add Standby Database wizard that helps you to create a broker configuration, if one does not already exist, having a primary database and a local or remote standby database. The wizard can create a physical or logical standby database (non-RAC) or import an existing physical or logical (RAC or non-RAC) standby database. If the wizard creates a physical or logical standby database, the wizard also automates the creation of the standby control file, server parameter file, online redo log files, and the standby datafiles.

- A switchover operation that helps you switch roles between the primary database and a standby database.

- A failover operation that changes one of the standby databases to the role of a primary database.

- Performance tools and graphs that help you monitor and tune redo transport services and log apply services.

- Property pages that allow you to set database properties on any database and, if applicable, the settings are immediately propagated to all other databases and server parameter files in the configuration.

- Event reporting through e-mail.

In addition, it makes all Oracle Net Services configuration changes necessary to support redo transport services and log apply services.

Figure 1-3 shows the Data Guard overview page in Oracle Enterprise Manager.

Figure 1-3 Data Guard Overview Page in Oracle Enterprise Manager

See Also:
Oracle Enterprise Manager online help

1.5.2 Data Guard Command-Line Interface (DGMGRL)

The Data Guard command-line interface (DGMGRL) enables you to control and monitor a Data Guard configuration from the DGMGRL prompt or within scripts. You can perform most of the activities required to manage and monitor the databases in the configuration using DGMGRL commands.

DGMGRL also includes commands to create an observer process that continuously monitors the primary and target standby databases and evaluates whether failover is necessary, and then initiates a fast-start failover when conditions warrant.

Table 1-2 lists the DGMGRL commands.

Table 1-2 DGMGRL Commands

Command

Description

ADD

Adds a standby database to the broker configuration

CONNECT

Connects to an Oracle instance

CREATE

Creates a broker configuration

DISABLE

Disables a configuration, a database, or fast-start failover

EDIT

Edits a configuration, database, or instance

ENABLE

Enables a configuration, a database, or fast-start failover

EXIT

Exits the program

FAILOVER

Changes a standby database to be the primary database

HELP

Displays description and syntax for individual commands

QUIT

Exits the program

REINSTATE

Changes a disabled database into a viable standby database

REM

Comments to be ignored by DGMGRL

REMOVE

Removes a configuration, database, or instance

SHOW

Displays information of a configuration, database, or instance

SHUTDOWN

Shuts down a currently running Oracle instance

START

Starts the fast-start failover observer

STARTUP

Starts an Oracle database instance

STOP

Stops the fast-start failover observer

SWITCHOVER

Switches roles between the primary database and a standby database

See Also:
Chapter 8 for complete reference information for the Data Guard command-line interface

1.6 Data Guard Monitor

The configuration, control, and monitoring functions of the broker are implemented by server-side software and configuration files that are maintained for each database that the broker manages. The software is called the Data Guard monitor.

The following sections describe how the Data Guard monitor interacts with the Oracle database and with remote Data Guard monitors to manage the broker configuration.

1.6.1 Data Guard Monitor (DMON) Process

The Data Guard monitor process (DMON) is an Oracle background process that runs for every database instance that is managed by the broker. When you start the Data Guard broker, a DMON process is created.

See Also:
Section 3.3 for information on starting the broker.

Whether you use Oracle Enterprise Manager or DGMGRL to manage a database, the DMON process is the server-side component that interacts with the local database and the DMON processes of the other databases 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 description of the configuration.

See Also:
Oracle Database Concepts for more information about the memory structures and processes that are used with an Oracle database

Figure 1-4 shows the broker's DMON process as one of several background processes that constitute an instance of the Oracle database. Figure 1-4 shows multiple databases, each having its own DMON process.

Figure 1-4 Databases With Broker (DMON) Processes

The zigzag arrow in the center of Figure 1-4 represents the two-way Oracle Net Services communication channel that exists between the DMON processes of two databases in the same broker configuration.

This two-way communication channel is used to pass requests between databases and to monitor the health of all of the databases in the broker configuration.

When creating a new Data Guard configuration or adding a new standby database into an existing configuration, the DMON process uses an initial connect identifier to connect to the database to collect necessary information about the database. This initial connect identifier is supplied by the user if DGMGRL is used, or constructed automatically if Oracle Enterprise Manager is used.

After the initial connection, the DMON process constructs connect descriptors for communication with other DMON processes on other databases, using the address value from the LOCAL_LISTENER initialization parameter from those databases. The DMON processes automatically manage the connections to each other. If a database is a RAC database, then as long as one instance in the database is running and the DMON process is started on the instance, that DMON process is able to establish two-way communications with other DMON processes on other databases to manage the database as part of the Data Guard configuration.

1.6.2 Configuration Management

The broker's DMON process persistently maintains profiles about all database objects in the broker configuration in a binary configuration file. A copy of this file is maintained by the DMON process for each of the databases that belong to the broker configuration. If it is a RAC database, each database's copy of the file is shared by all instances of the database.

This configuration file contains profiles that describe the states and properties of the databases in the configuration. For example, the file records the databases that are part of the configuration, the roles and properties of each of the databases, and the state of each database in the configuration.

The configuration data is managed transparently by the DMON process to ensure that the configuration information is kept consistent across all of the databases. The broker uses the data in the configuration file to configure and start the databases, control each database's behavior, and provide information to DGMGRL and Oracle Enterprise Manager.

See Also:
Section 4.3 for more information

Whenever you add databases to a broker configuration, or make a change to an existing database's properties, each DMON process records the new information in its copy of the configuration file.

1.6.3 Database Property Management

Associated with each database are various properties that the DMON process uses to control the database's behavior. The properties are recorded in the configuration file as a part of the database's object profile that is stored there. Many database properties are used to control database initialization parameters related to the Data Guard environment.

To ensure that the broker can update the values of parameters in both the database itself and in the configuration file, you must use a server parameter file to control static and dynamic initialization parameters. The use of a server parameter file gives the broker a mechanism that allows it to reconcile property values selected by the database administrator (DBA) when using the broker with any related initialization parameter values recorded in the server parameter file.

When you set values for database properties in the broker configuration, the broker records the change in the configuration file and propagates the change to all of the databases in the Data Guard configuration.

Note:
The broker supports both the default and nondefault server parameter file filenames. If you use a nondefault server parameter filename, the initialization parameter file must include the complete filename and location of the server parameter file. If this is a RAC database, there must be one nondefault server parameter file for all instances.

See Also:
Section 4.3.2 for more information.

2 Oracle Data Guard Installation

This chapter includes the following topics:

- Oracle Data Guard Installation

- Prerequisites for First Use

See Also:
Appendix B for help with upgrading the Oracle databases and Oracle Enterprise Manager in a Data Guard broker configuration

2.1 Oracle Data Guard Installation

Oracle Data Guard is included with the Enterprise Edition and Personal Edition of the Oracle database software. A Data Guard configuration may be managed by using either SQL*Plus, or Data Guard broker's command-line interface (DGMGRL), or Oracle Enterprise Manager 10g Grid Control.

To use DGMGRL, the best practice is to install the Oracle Enterprise Edition or Personal Edition database software on each location you expect to include in broker configurations. You must install Oracle Enterprise Manager 10g Grid Control to use the Enterprise Manager Web-based user interface for Data Guard.

In addition, to 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 in the following list:

- Install the complete Oracle Client Administrator by choosing the Administrator option from Oracle Universal Installer.

This installation includes DGMGRL but it does not include the Oracle Enterprise Manager agent. This allows 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.

Note:
The operating system on the observer computer can be different from the operating system running on the primary computer or target standby database computer. However, the operating system for the primary database computer and all associated standby database computers must be the same.

2.2 Prerequisites for First Use

The following conditions must be true before you can use the broker:

- The primary and standby databases must be running Oracle Database 10g (10.2) and each can be installed in either a single-instance or multi-instance environment. The database must be licensed for Oracle Enterprise Edition or Personal Edition.

- You must use a server parameter file (SPFILE) to ensure the broker can persistently reconcile values between broker properties and any related initialization parameter values. See Section 4.3.2 for more information.

- The value of the DG_BROKER_START parameter must be set to TRUE. See Section 3.3 for more information. (Enterprise Manager sets this parameter automatically.)

- If any of the databases in the configuration is a RAC database, you must set up the DG_BROKER_CONFIG_FILEn initialization parameters for that database such that they point to the same shared files for all instances of that database. The shared files could be files on a cluster file system, if available, on raw devices, or stored using Automatic Storage Management (ASM).

See Also:
Configuration file information in Section 1.6.2. Section 3.2 for details about setting up the broker configuration file, and Section 3.2.2.2 for details about sizing the raw devices.

- Oracle Net Services network files must be set up on the primary database and on the standby database if you configure an existing standby database into the broker configuration. Otherwise, Enterprise Manager automatically sets up the network files when it creates a standby database.

- If you are using a nondefault port number (for example, something other than port 1521) for the local listener address, you must set the LOCAL_LISTENER initialization parameter on each instance that is part of a broker configuration to a listener address that is reachable by all members of the configuration. See the Oracle Database Reference and the Oracle Database Net Services Administrator's Guide for additional information.

- To enable DGMGRL 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 for the GLOBAL_DBNAME attribute must be set to a concatenation of db_unique_name_DGMGRL.db_domain. For example, in the LISTENER.ORA file:

LISTENER = (DESCRIPTION =
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=host_name)
(PORT=port_num))))
SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SID_NAME=sid_name)
(GLOBAL_DBNAME=db_unique_name_DGMGRL.db_domain)
(ORACLE_HOME=oracle_home)))

- Any database, including instances of the database, managed by the broker must be mounted.

- If any of the databases in the configuration is a RAC database, the START_OPTIONS for that database must be set to MOUNT in the Oracle Cluster Repository (OCR) using srvctl as follows:

srvctl add database -d <db_unique_name> -o <$oracle_home> -s mount
or
srvctl modify database -d <db_unique_name> -o <$oracle_home> -s mount

- The primary database must be opened in ARCHIVELOG mode.

- You must set the COMPATIBLE initialization parameter to 9.2.0.1.0 or higher for both the primary and standby databases. However, if you want to take advantage of new Oracle Database 10g features, set the COMPATIBLE parameter to 10.2.0.0.

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

See Also:
Section 3.3 for more information about preparing and starting the Oracle Data Guard broker. See Oracle Data Guard Concepts and Administration for more information about setting up the network files.

3 Managing Broker Configurations

This chapter contains the following sections:

- Section 3.1, "Configuration Support"

- Section 3.2, "Setting Up the Broker Configuration Files"

- Section 3.3, "Starting the Data Guard Broker"

- Section 3.4, "Management Cycle of a Broker Configuration"

- Section 3.5, "Enable and Disable Operations"

- Section 3.6, "Configuration Status"

3.1 Configuration Support

The broker enables you to logically define a Data Guard configuration, consisting of a primary database and one or more standby databases. With the broker, you define a broker configuration that is a logical grouping of the databases, including redo transport services and log apply services. At the DBA's discretion, the broker controls the logical objects in the configuration, modifies their behavior at runtime, monitors the overall health of the configuration, and reports any health and other operational characteristics up through the Oracle Enterprise Management notification mechanisms if you are using Oracle Enterprise Manager, or through SHOW commands if you are using DGMGRL.

The broker supports Data Guard configurations consisting of a primary database, and up to nine standby databases that are either local to, or, remote from, the primary database. Any of those databases can be an Oracle Real Application Clusters (RAC) database.

A supported Data Guard configuration contains the following components:

- A (RAC or non-RAC) primary database

- From one to nine physical or logical (RAC or non-RAC) standby databases

- Physical systems that host the primary and standby databases

- Oracle Net Services network configuration that defines a connection between the databases

- Standby (archived redo log files) destination parameters and configuration properties

- Redo transport services that transmit the redo data from the primary database to the standby databases

- Log apply services that apply redo data to the standby databases from the archived redo log files or standby redo log files

The Data Guard log apply services update standby databases with redo data that is transmitted automatically from the primary database by redo transport services. The archived redo log files and standby redo log files contain all of the database changes except for unrecoverable or unlogged changes. On physical standby databases, Redo Apply applies the redo data to stay transactionally consistent with the primary database. On logical standby databases, SQL Apply applies the redo data to stay transactionally consistent with the primary database.

The broker's Data Guard monitor (DMON) process configures and maintains the broker configuration as a group of objects that you can manage and monitor as a single unit. Thus, when you enter a command that affects multiple databases, the DMON process:

- Carries out your request on the primary database

- Coordinates with the DMON process for each of the other databases, as required for your request

- Updates the configuration file on the local system

- Communicates with the DMON process for each of the other databases to update their copies of the configuration file

Through the DMON process, you can configure, monitor, and control the databases and the configuration together as a unit. If you disable the configuration, broker management of all of the databases in the configuration is also disabled. If you later enable the configuration, broker management is enabled for each database in the configuration.

Figure 3-1 shows a two-database broker configuration with the DMON process running at each location and communicating over Oracle Net.

On the primary database, the figure shows the redo transport services in addition to the following main components: the primary database, DMON, the online redo log files, and the archived redo log files. The figure also shows standby redo log files in outline form on the primary side; the standby redo logs are outlined to indicate they are currently inactive but have been configured in preparation for a switchover to the standby role.The standby database includes the following components: a standby database, log apply services, DMON, archived redo log files, and standby redo log files. The online redo log files on the standby database are outlined to indicate they are currently inactive but have been configured in preparation for a switchover to the primary role.

See Also:
Oracle Data Guard Concepts and Administration for more information about physical and logical standby databases

Figure 3-1 Oracle Data Guard Broker Configuration

3.2 Setting Up the Broker Configuration Files

Two copies of the configuration file are maintained for each database so as to always have a record of the last known valid state of the configuration. When the broker is started for the first time, the configuration files are automatically created and named using a default path name and filename that is operating-system specific. You can override this default path name and filename by setting the following initialization parameters for that database:

DG_BROKER_CONFIG_FILE1
DG_BROKER_CONFIG_FILE2

Note the following restrictions when setting the DG_BROKER_CONFIG_FILE1 and DG_BROKER_CONFIG_FILE2 initialization parameters:

- The parameters must be set to the same value for each instance if this is a RAC database.

- These parameters can only be set or changed when the Data Guard broker is not running (DG_BROKER_START=FALSE).

- These parameters must specify a raw device, ASM file, or cluster file system file that resolves to the same set of physical files for all RAC instances.

The Data Guard Broker works with databases that use either Oracle managed or user managed datafiles. These datafiles can reside on raw devices, a file system or an ASM disk group. The following section contains these topics:

- Renaming the Broker Configuration Files

- Managing Broker Configuration Files in a Real Application Clusters Environment

3.2.1 Renaming the Broker Configuration Files

You can change the configuration filenames dynamically by issuing the ALTER SYSTEM SQL statement. However, you cannot alter these parameters when the broker's DMON process is running. To change the names of these configuration files for a given database, perform the following steps:

1. Disable the broker configuration using the DGMGRL DISABLE command. See Section 3.5.

2. Stop the Data Guard broker DMON process using the following SQL statement:

SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;

3. Change the configuration filenames for the database:

SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1=filespec1
SQL> ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2=filespec2

Note:
If the broker is managing a RAC database, the value of DG_BROKER_CONFIG_FILE1 and the value of DG_BROKER_CONFIG_FILE2 for each of the instances must point to the same set of physical files.

4. If the configuration files are not located on raw devices, rename the existing files to filespec1 and filespec2, respectively, at the operating system level to avoid losing the existing broker configuration information. If the files are located on raw devices, you must manually move the contents from the old location to the new location.

5. Restart the Data Guard broker DMON process, as follows:

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

6. Enable the broker configuration using the DGMGRL ENABLE command or the Enable operation in the Data Guard management pages of the Enterprise Manager.

3.2.2 Managing Broker Configuration Files in a Real Application Clusters Environment

If the broker is managing a RAC database, the value of DG_BROKER_CONFIG_FILE1 and the value of DG_BROKER_CONFIG_FILE2 for each of the instances must point to the same set of physical files. In other words, all instances of the database must reference the same set of configuration files. The configuration files can be deployed using one of the following methods:

- Using Cluster File System (CFS) for Configuration Files

- Using ASM Disk Groups for Configuration Files

- Using Raw Devices for Configuration Files

3.2.2.1 Using Cluster File System (CFS) for Configuration Files

If cluster file system (CFS) is available, and the configuration files reside there, the DG_BROKER_CONFIG_FILEn parameters on all of the instances must be set to these files including the path to the CFS area. Figure 3-2 shows the set up for the broker configuration files on CFS. In this scenario, the parameters and value for all instances would be:

DG_BROKER_CONFIG_FILE1=$ORACLE_BASE/admin/db_unique_name/dr1db_unique_name.dat
DG_BROKER_CONFIG_FILE2=$ORACLE_BASE/admin/db_unique_name/dr2db_unique_name.dat

Figure 3-2 Broker Configuration Setup in a CFS Area

3.2.2.2 Using ASM Disk Groups for Configuration Files

The broker's configuration files can also reside on an ASM disk group. Figure 3-3 shows the setup for the broker configuration files on ASM devices. In this scenario, the parameters and values would be specified, as follows:

ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1 = '+DG/DIRECTORY/DR1.DAT' SCOPE=BOTH;
ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2 = '+DG/DIRECTORY/DR2.DAT' SCOPE=BOTH;

Figure 3-3 Broker Configuration Setup with ASM

Because the configuration files must be explicitly named by the user, these configuration files are not Oracle Managed Files (OMF).To create the broker's configuration files on an ASM disk group, set the DG_BROKER_CONFIG_FILE1 and DG_BROKER_CONFIG_FILE2 initialization parameters to a string value that includes the name of an existing ASM disk group, an existing directory in that disk group, and the name of the configuration file itself.

3.2.2.3 Using Raw Devices for Configuration Files

If CFS is not available and you are not using ASM, the files must be on raw devices. In this case, the parameter values on each of the instances must point to the raw devices. Figure 3-4 shows the set up for the broker configuration files on raw devices. On a UNIX system, you would set this up similar to the following on each node:

%ln -s /dev/rdsk/c1t2d3s5 dr1/<db_unique_name>.dat
%ln -s /dev/rdsk/c1t2d3s6 dr2/<db_unique_name>.dat

Figure 3-4 Broker Configuration Setup with Raw Devices

If the broker configuration files need to be on raw devices, set up two additional raw devices of 1MB each. Set up the value of the DG_BROKER_CONFIG_FILE1 and DG_BROKER_CONFIG_FILE2 parameters to point to the raw devices. A 1MB configuration file will accommodate 10 databases with a total of 45 instances between them.

You may need a larger device if the number of instances for this configuration exceeds 45 instances. You will need 15KB for each additional instance.

3.3 Starting the Data Guard Broker

After setting up the configuration files, the DG_BROKER_START initialization parameter must be set to TRUE for each database to start the DMON processes.

By default, the DG_BROKER_START initialization parameter is set to FALSE. However, you can set the value in the following ways:

- If you are using Oracle Enterprise Manager, it automatically sets the DG_BROKER_START initialization parameter to TRUE for new standby databases that it creates.

- If you are using DGMGRL, you must explicitly set the DG_BROKER_START initialization parameter to TRUE; otherwise, the DMON process will not start. You can set the DG_BROKER_START initialization parameter with the following SQL statement:

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

System altered.

SQL> SHOW PARAMETER DG_BROKER_START

NAME               TYPE      VALUE
------------------------------------
dg_broker_start    boolean   TRUE

Whether you use Enterprise Manager or DGMGRL, set the value of the DG_BROKER_START initialization parameter to TRUE in the server parameter file on each primary and standby database. Doing so ensures that the DMON processes will start automatically the next time you start any instance of the database.

3.4 Management Cycle of a Broker Configuration

The broker helps you to create a new configuration or manage an existing configuration. Figure 3-5 shows the life cycle of a broker configuration.

Figure 3-5 Life Cycle of a Broker Configuration and Its Databases

Create the Broker Configuration

When using Enterprise Manager, the Add Standby Database wizard can either add an existing (RAC or non-RAC) standby database into the configuration or create a new (non-RAC only) standby database and add it to the configuration. The standby database can be either a physical or logical database.

When using DGMGRL, the primary database and a standby database must already exist. You construct the standby database from backups of the primary database control files and datafiles, and then prepare it for recovery.

See Also:
Chapter 6 and Chapter 7 that describe the preparation requirements if you are using Enterprise Manager or DGMGRL, respectively

Enable the Broker Configuration

A Data Guard configuration must be enabled to be managed or monitored by the broker. Conversely, you disable a configuration if you no longer want to manage it with the broker. When you disable a configuration, broker management of all of its databases is also disabled.

Note:
You can enable or disable the configuration using DGMGRL. You cannot disable the configuration using Enterprise Manager. You can enable the configuration using Enterprise Manager in the event that it was previously disabled using DGMGRL.

A broker configuration, when first created using Enterprise Manager, is automatically enabled as soon as the Add Standby Database wizard completes.

A broker configuration, when first created using DGMGRL, is in a disabled condition. This means its constituent databases are not yet under active control of the broker. When you finish configuring the databases into a broker configuration with DGMGRL, you must enable the configuration to allow the broker to manage the configuration.

You can enable:

- The entire configuration, including all of its databases

- An individual standby database

You can easily disable a database if a problem occurs and you can no longer function properly in the broker configuration.

You may also want to disable a configuration temporarily, and then change some properties in the broker configuration without affecting the actual database properties. The changed properties will take effect when the configuration is enabled again for management by the broker.

Make Role Changes Within the Broker Configuration, As Needed

At any time, you can issue a single command to change the roles of the databases in the configuration. If some event renders the primary database unusable, you can fail over one of the standby databases to become the new primary database.

In addition, planned downtime for maintenance can be reduced because you can quickly switch over production processing from the current primary database to a standby database, and then switch back again after the planned maintenance.

See Also:
Chapter 5 for more information about role changes

Make State Changes to the Databases, As Needed

The broker transitions the databases into an online state, by default, the first time that you enable the database.

At any time, you can issue a single command through Enterprise Manager or DGMGRL to change the state of the database. For example, you could bring the primary database into a LOG-TRANSPORT-OFF state to temporarily stop archiving log files to the standby database. Then, you issue another command to return the database to a full online state (that is, online and archiving log files to the standby databases).

See Also:
Chapter 4 for more information about database state changes

Update Database Properties, As Needed

The broker enables you to set database properties, some of which correspond to database initialization parameters. You can change these properties to dynamically control such things as redo transport, file management, log apply, and to support the overall configuration protection mode. The broker records the changes in the broker configuration file for each database in the Data Guard configuration and propagates the changes to the related initialization parameters in the server parameter files, if needed.

See Also:
Chapter 4 and Chapter 9 for complete information about database properties

Set Data Protection Levels, As Needed

The broker enables you to set the data protection level for the configuration. You can configure the protection mode to maximize data protection, maximize availability, or maximize performance.

See Also:
Section 4.6 for information about managing data protection modes

Monitor the Configuration

You can check the health of the configuration, display and update the properties of the databases, and set Oracle Enterprise Manager events.

Enterprise Manager also provides a dynamic performance page that automatically and dynamically refreshes chart data and status at specified intervals. The performance chart shows a graphical summary of how far behind and how much redo data is being generated and applied.

See Also:
Chapter 6 and Chapter 7 for scenarios that show examples using Enterprise Manager and DGMGRL, respectively

3.5 Enable and Disable Operations

A key concept of management with the broker is the notion of enabling and disabling broker management of the databases in a broker configuration. The enable and disable operations are defined for databases that were incorporated into a broker configuration; you cannot perform these broker operations on databases that are not part of the broker configuration. This is because when you enable or disable a database in the broker configuration, you are effectively enabling or disabling the ability of the DMON process to:

- Manage and monitor the specified database.

- Manage the profile information in the broker configuration file for each database.

However, disabling a broker configuration does not affect current services and operations in the actual Data Guard configuration. For example, when you disable a broker configuration, redo transport services and log apply services in the Data Guard configuration continue to function unchanged, but you can no longer manage them through the broker interfaces.

In addition, disabling a database does not remove or delete its profile from the broker configuration file. You can reenable your ability to manage with the broker using the DGMGRL ENABLE CONFIGURATION or ENABLE DATABASE commands, or the Enable option in the Data Guard management pages of Enterprise Manager.

Note:
You can enable or disable the configuration using DGMGRL. You cannot disable the configuration using Enterprise Manager. You can enable the configuration using the Enterprise Manager in the event that it was previously disabled using DGMGRL.

Caution:
If you disable broker management of a standby database in the broker configuration, that standby database cannot be used by the broker as a failover target in the event of loss of the primary database.

Disabling broker management of the configuration may be useful to do even though you are removing the broker's ability to monitor and control the databases. For example, it may be advantageous to disable a configuration temporarily in order to change one or more properties in the broker configuration all at the same time. When you change properties in a disabled configuration, it does not affect the actual database properties underneath because the changes are not applied to the running database until you reenable the configuration. For example, you might want to change the overall configuration protection mode and the redo transport services properties on a disabled configuration so that all changes are applied to the configuration at the same time upon the next enable operation.

Note:
For Oracle9i, the configuration object is in either an online or offline state. For Oracle Database 10g, the configuration object is always in an online state.

See Also:
Section 4.6.2, "How the Protection Modes Influence Broker Operations"

3.6 Configuration Status

A configuration status reveals the overall health of the configuration. Status of the configuration is acquired from the status of all of its databases.

The following list describes the possible status modes for a configuration:

- Normal

The configuration, including all of the databases configured in it, is operating as specified by the user without any warnings or errors.

- Warning

One or more of the databases in the configuration are not operating as specified by the user. To obtain more information, use the DGMGRL SHOW command or the Enterprise Manager display to locate each database and examine its error status to reveal the source of the problem.

- Error

One or more of the databases in the configuration failed or may no longer be operating as specified by the user. To obtain more information, use the DGMGRL SHOW command or the Enterprise Manager display to locate each database and examine its error status to reveal the source of the problem.

- Unknown/Disabled

Broker management of the configuration is disabled and the broker is not monitoring the status of the databases in the configuration.

4 Managing Databases

This chapter describes managing the states and properties that are specific to the database. This chapter contains the following sections:

- Section 4.1, "Database Objects"

- Section 4.2, "Database States"

- Section 4.3, "Database Properties"

- Section 4.4, "Managing Redo Transport Services"

- Section 4.5, "Managing Log Apply Services"

- Section 4.6, "Managing Data Protection Modes"

- Section 4.7, "Database Status"

4.1 Database Objects

The broker manages database objects. A database object corresponds to a primary or standby database. The broker uses each object's profile to manage and monitor the state of a single database.

The broker distinguishes between physical and logical standby databases. These databases are configured with profiles having states and properties that are appropriate for their standby types.

4.2 Database States

When a configuration is enabled, its databases can be in one of several states. Table 4-1 describes all of the possible primary and standby database states.

Table 4-1 Database States and Descriptions

Database Role

State Name

Description

Primary

ONLINE

The primary database is open for read/write access and redo transport services are archiving online redo log files to the standby databases.

If this is a RAC database, all started instances are open in read/write mode and have redo transport services running.

This is the default state for a primary database when it is enabled for the first time.

Primary

LOG-TRANSPORT-OFF

The primary database is open for read/write access, but redo transport services are not transmitting redo data to the standby databases.

If this is a RAC database, all started instances are open in read/write mode and redo transport services are not running on any instances.

Physical standby

ONLINE

The physical standby database is mounted and Redo Apply is started. The standby database is not open for read-only queries.

If the standby database is a RAC database, the broker starts log apply services on exactly one standby instance, called the apply instance. If this instance fails, the broker automatically chooses another started instance. This new instance then becomes the apply instance.

This is the default state for a physical standby database when it is enabled for the first time.

Physical standby

LOG-APPLY-OFF

The physical standby database is mounted, but Redo Apply is stopped. The standby database is not open for read-only queries.

If this is a RAC database, there is no instance running log apply services until you change the database state to ONLINE.

Physical standby

READ-ONLY

The physical standby database is open for read-only queries, and Redo Apply is stopped.

If this is a RAC database, one or more instances will be open in read-only mode. Redo Apply is not running on any instance.

Logical standby

ONLINE

The logical standby database is open for read-only queries and SQL Apply is started. The logical standby database guard is on.

If this is a RAC database, SQL Apply is running on one instance, the apply instance. If this instance fails, the broker automatically chooses another started instance. This new instance becomes the apply instance.

This is the default state for a logical standby database when it is enabled for the first time.

Logical standby

LOG-APPLY-OFF

The logical standby database is open for read-only queries, and SQL Apply is not running. The logical standby database guard is on.

If this is a RAC database, there is no instance running SQL Apply until you change the database state to ONLINE.

All

OFFLINE

When you set the state of a standby database to OFFLINE, the broker automatically shuts down the database, turns off redo transport services to this database, and leaves the database as disabled in the broker configuration. The broker will not manage this database until you restart the database.

When you set the state of a primary database to OFFLINE, the broker automatically shuts down the database. The primary database is not available, and the broker is no longer managing the entire Data Guard configuration. You need to restart the database to resume broker control.

If this is a RAC database, all started instances are shutdown.

4.2.1 Database State Transitions

Figure 4-1 graphically shows the possible transitions between the states that were described in Table 4-1. The figure shows the database state transitions that can occur on a primary database, a physical standby database, and a logical standby database. This figure has three groupings of circles representing each state (one group for each database type) with arrows showing the transitions that are allowed between the states on each database.

Figure 4-1 Database State Transition Diagrams

You can use the DGMGRL EDIT DATABASE command to explicitly change the state of a database. For example, the EDIT DATABASE command in the following example changes the state of the North_Sales database to LOG-TRANSPORT-OFF.

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='LOG-TRANSPORT-OFF';
Succeeded.

See Also:
Chapter 8 for complete information about the EDIT DATABASE command. See Chapter 6 for examples of performing state transitions using Enterprise Manager.

The following sections describe in more detail the possible state transitions for primary and standby databases.

Primary database state transitions

For the primary database, when transitioning from any state to the ONLINE state, the broker sets up redo transport services to all broker-managed standby databases using the log transport-related properties of the standby databases. See Section 4.4 for the list of all log transport-related properties. Redo transport services setup is done by setting the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_DEST_STATE_n initialization parameters on the primary database, and the LOG_ARCHIVE_CONFIG initialization parameter on all databases (primary or standby). If necessary, the broker also sets up the data protection mode of the database to match the protection mode recorded in the broker configuration file, and opens the database for read and write access. Finally, the broker switches a log for each thread to initiate redo transport services.

When transitioning from any state to the LOG-TRANSPORT-OFF state, the broker turns off redo transport services to all broker-managed standby databases by resetting the LOG_ARCHIVE_DEST_STATE_n initialization parameter. Transmission of redo data to all broker-managed standby databases is stopped. Log files continue to be archived at the primary database.

When transitioning to the OFFLINE state, the broker shuts down the primary database. The primary database is not available, and the broker is no longer managing the configuration. To transition out of the OFFLINE state, you need to start up the database in the mounted mode. The broker will restore the primary database to the ONLINE state.

Note:
Before setting the state to OFFLINE, you should carefully consider whether or not the interruption in access to data and computing resources is necessary.

If the primary database is a RAC database, the broker configures redo transport services on all primary instances with the exact same settings.

See Also:
Section 4.4 for more details on managing redo transport services

Physical standby database state transitions

For a physical standby database, when transitioning from any state to the ONLINE state, the broker starts Redo Apply with options specified by the log apply-related properties. See Section 4.5 for the property list. If the standby database is a RAC database, the broker starts Redo Apply on one standby instance, called the apply instance.

When transitioning to the LOG-APPLY-OFF state, the broker stops Redo Apply if the database is in the ONLINE state, or closes the database if the database is in the READ-ONLY state.

When transitioning to the READ-ONLY state, the broker stops Redo Apply if it is running, and opens the database for read-only access. If the standby database is a RAC database, all currently active instances will be open READ-ONLY.

Note:
Before you transition a physical standby database from a READ-ONLY state to any other state, it is recommended that you first close all open sessions of the standby database. If some of the sessions are not closed, the broker will automatically shut down all pending user sessions during the state transition.

When transitioning to the OFFLINE state, the broker shuts down the standby database. The standby database is not available, the broker stops redo transport services to this database, and the broker stops managing this database. To transition out of the OFFLINE state, you need to start up the database in the mounted mode. The broker restores the standby database to the state it was in before the OFFLINE state.

See Also:
Section 4.5 for more details on managing Redo Apply

Logical standby database state transitions

For a logical standby database, when transitioning from any state to the ONLINE state, the broker opens the database if it is not yet opened, enables the database guard to prevent modifications to tables in the logical standby database, and starts SQL Apply with options specified by the log apply-related properties. If the logical standby database is a RAC database, the broker starts SQL Apply on one standby instance, the apply instance.

When transitioning to the LOG-APPLY-OFF state, the broker stops SQL Apply.

When transitioning to the OFFLINE state, the broker shuts down the logical standby database. The logical standby database is not available, the broker stops redo transport services to this database, and the broker stops managing this database. To transition out of the OFFLINE state, you need to start up the database in the mounted mode. The broker restores the standby database to the state it was in before the OFFLINE state.

See Also:

- Section 4.5 for information about managing SQL Apply

- Oracle Data Guard Concepts and Administration for information about the database guard

4.3 Database Properties

There are two types of properties: monitorable and configurable. Both monitorable and configurable properties can be further defined into those properties that have database scope and those having instance scope.

- Monitorable property values can be viewed only when the associated object is enabled.

Monitorable properties allow you to view information related to database objects, but you cannot change the values of these properties.

- Configurable property values can be viewed and dynamically updated.

Configurable properties affect the operation or configuration of the broker. You can change the value of these properties using DGMGRL or Enterprise Manager. You can edit properties if the configuration and its databases are enabled, disabled, online, or offline. However, if the database is disabled, the new property value will not take effect until you enable the configuration or database, as appropriate.

See Also:
Chapter 9 for a detailed list of all database properties

To see these properties, you might use the DGMGRL SHOW command or Edit Properties page in Enterprise Manager. Example 4-1 uses the SHOW DATABASE VERBOSE command to display information about the North_Sales database.

Example 4-1 Using the SHOW DATABASE VERBOSE Command to Display Properties

DGMGRL> SHOW DATABASE VERBOSE 'North_Sales' ;

Database
Name:            North_Sales
Role:            PRIMARY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
sales1

Properties:
InitialConnectIdentifier        = 'North_Sales.foo.com'
LogXptMode                      = 'ARCH'
Dependency                      = ''
DelayMins                       = '0'
Binding                         = 'OPTIONAL'
MaxFailure                      = '0'
MaxConnections                  = '0'
ReopenSecs                      = '30'
NetTimeout                      = '180'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/s2t, dbs/t'
LogFileNameConvert              = 'dbs/s2t, dbs/t'
FastStartFailoverTarget         = ''
StatusReport                    = '(monitor)'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
HostName                        = 'north.foo.com'
SidName                         = 'sales1'
LocalListenerAddress            =
'(ADDRESS=(PROTOCOL=TCP)(HOST=north.foo.com)(PORT=1514))'
StandbyArchiveLocation          = '/archfs/arch/'
AlternateLocation               = ''
LogArchiveTrace                 = '255'
LogArchiveFormat                = 'r_%d_%t_%s_%r.arc'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'
Current status for "North_Sales":
SUCCESS

See Also:
Chapter 8 for complete information about the DGMGRL command-line interface

4.3.1 Monitorable (Read-Only) Properties

Monitorable properties allow you to view information related to the database, but you cannot change the values of these properties. These properties can be very helpful when you are trying to diagnose problems in the broker configuration. For example, you can view the InconsistentLogXptProps property to determine where there is a discrepancy in redo transport services properties between the broker configuration file and the actual value currently used by the database.

You can list all monitorable properties using the DGMGRL SHOW DATABASE VERBOSE command. Use the SHOW DATABASE command to obtain more details about a particular property. For example, the following shows the InconsistentLogXptProps property:

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES

INSTANCE_NAME    STANDBY_NAME    PROPERTY_NAME    MEMORY_VALUE    BROKER_VALUE
sales1           DR_Sales        DelayMins        30              10

Enterprise Manager displays the information obtained from these properties on the Edit Properties page.

4.3.2 Configurable (Changeable) Database Properties

Configurable properties affect the operation or configuration of the database. When you use DGMGRL or Enterprise Manager to create a primary database object and import existing standby databases into a new broker configuration, the property values are initially imported from the database settings.

You can update many property values when the database is either disabled or enabled. When a new database is added into the configuration, the broker connects to the database and imports initial values for the database properties from the current database settings. For example:

DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget';
ArchiveLagTarget = '0'

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'ArchiveLagTarget'=1200;
Property "ArchiveLagTarget" updated

DGMGRL> SHOW DATABASE 'North_Sales' 'ArchiveLagTarget';
ArchiveLagTarget = '1200'

When the configuration is enabled, the broker keeps the database property values in the broker configuration file consistent with the values being used in the database. For those that are related to initialization parameter properties, the broker maintains the consistency among the value in the broker configuration file, the current database value, and the initialization parameter value in the server parameter file, as follows:

- For dynamic parameters, the broker keeps the value of the database parameter consistent in the system global area (SGA) for the instance, in the broker configuration file, and in the server parameter file.

- For static parameters and properties, the database parameter value in the system global area (SGA) for the instances may temporarily differ from what is in the broker configuration file and in the server parameter file. Typically, the database value becomes the same as the server parameter file value and the broker configuration file value the next time the database instance is stopped and restarted.

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 server parameter file and the settings in memory the next time you enable the broker configuration.

Note:
Even though you can change a property value when the configuration is disabled, the change does not take effect on the database unless the configuration is enabled. Also note that some property values can only be changed in the disabled state.

4.4 Managing Redo Transport Services

To manage redo transport services, you specify the following set of configurable properties on each standby database:

- AlternateLocation

- Binding

- Dependency

- LogShipping

- LogXptMode

- MaxFailure

- NetTimeout

- ReopenSecs

- StandbyArchiveLocation

You can use these properties to specify how the broker configures redo transport services for the standby database. The actual redo transport setup, such as setting the LOG_ARCHIVE_DEST_n initialization parameter, is carried out by the broker on the primary database (except for the StandbyArchiveLocation property). If changing the property requires that you change the LOG_ARCHIVE_DEST_n initialization parameter attributes, the broker forces a log switch on each thread so that the new setting is adopted immediately by the primary database.

You may also preset these properties on the primary database in preparation for it to be switched over to a standby database.

4.4.1 Managing Redo Transport Services for Data Protection Modes

Section 4.6 describes how the broker handles data protection modes. As a part of the overall configuration protection mode, you must ensure that redo transport services are also properly set up for the data protection mode that you choose.

You use the LogXptMode property to set the SYNC, ASYNC, or ARCH mode for redo transport services. See Table 4-2 for additional information about protection modes and redo transport services.

The values for the LogXptMode property are described in the following list:

SYNC

Configures redo transport services for this 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 service enables the highest grade of data protection to the primary database, but also incurs the highest performance impact.

ASYNC

Configures redo transport services for this 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 lower performance impact.

ARCH

Configures redo transport services for this standby database using the ARCH attribute of the LOG_ARCHIVE_DEST_n initialization parameter. Standby redo log files are not required. This mode enables the lowest grade of protection to the primary database, and the lowest performance impact.

Note:
When you change the protection mode, Enterprise Manager automatically sets up standby redo log files on one or more standby databases in your configuration, and on the primary database in preparation for switchover. If you use DGMGRL, you must create standby redo log files using the procedure described in Oracle Data Guard Concepts and Administration.

4.4.2 Turning On and Off Redo Transport Services

Turn redo transport services on and off by setting the state of the primary database. Setting the primary database state to ONLINE turns on redo transport services to the standby databases, and setting the primary database state to LOG-TRANSPORT-OFF turns off redo transport services to all the standby database.

Note:
Oracle does not recommend turning off redo transport services to all standby databases. This increases the risk of data loss if the primary database fails.

Turn redo transport services on and off to an individual standby database using the LogShipping property on the standby database. The LogShipping property accepts values ON and OFF. If you set the LogShipping property to OFF for a standby database, redo transport services to this standby database are turned off, while redo transport services to other databases are not affected. You can set LogShipping to ON to turn back on redo transport services to the standby database.

The relationship between setting the primary database state and setting the LogShipping property is as follows:

- If the primary database state is set to LOG-TRANSPORT-OFF, redo transport services to all the standby databases are turned off regardless of the LogShipping property values of the individual standby databases.

- If the primary database state is set to ONLINE, redo transport services to each standby database are determined by the LogShipping property of that database.

Example 4-2 and Example 4-3 show how to turn off redo transport services in two different scenarios.

Example 4-2 Turn Off Redo Transport Services to All Standby Databases

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE="LOG-TRANSPORT-OFF";
Succeeded.
DGMGRL> SHOW DATABASE 'North_Sales';

Database
Name:            North_Sales
Role:            PRIMARY
Enabled:         YES
Intended State:  LOG-TRANSPORT-OFF
Instance(s):
sales1

Current status for "North_Sales":
SUCCESS

Example 4-3 Turn Off Redo Transport Services to a Specific Standby Database

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogShipping'='OFF';
Property "LogShipping" updated

DGMGRL> SHOW DATABASE 'DR_Sales' 'LogShipping';
LogShipping = 'OFF'

4.4.3 Specifying Locations for Archived Redo Log Files

You can set up locations on the standby database to store the archived redo log files to be used by log apply services on the standby database. This is done by setting the StandbyArchiveLocation and AlternateLocation properties on the standby database.

StandbyArchiveLocation specifies a standby location where the archived redo log files will be stored. The broker ensures that the archived redo log files are stored in the same specified location whether or not the standby database has standby redo log files. The broker only manages the location on the standby database to store archived redo log files received from the primary database. For archived redo log files generated locally when the database is either the primary database or a logical standby database, you need to set up local destinations directly through the LOG_ARCHIVE_DEST_n initialization parameter. The broker allows the value of StandbyArchiveLocation to be the same as the location you set up for locally generated logs, in which case the broker sets up the VALID_FOR attribute of the destination appropriately so that it can be used for both the archived redo log files received from the primary database and archived redo log files generated locally.

Note:
On a logical standby database, Oracle recommends that the LOCATION attribute of the LOG_ARCHIVE_DEST_n initialization parameter for the local destination be different from the value of either the StandbyArchiveLocation or AlternateLocation property.

The broker does not manage the local destinations for locally-generated archived redo log files, but the broker does ensure that the location specified by StandbyArchiveLocation is not used to store locally-generated archived redo log files. (This is done by setting the VALID_FOR attribute of the destination to be (STANDBY_ROLE,STANDBY_LOGFILE).)

You can also set up an alternate location to store archived redo log files on the standby using the AlternateLocation property on the standby database. This is useful for avoiding disk capacity problems or disk errors when archiving the online redo log files on the standby database. AlternateLocation specifies a standby location where the archived redo log files will be stored if the location specified by the StandbyArchiveLocation fails. The broker sets up the alternate location properly using the ALTERNATE attribute of the LOG_ARCHIVE_DEST_n initialization parameter.

Note:
If the flash recovery area is set up on the standby database and you have configured it to store archived redo log files from the primary database, the broker no longer manages the standby locations. In this case, the broker disallows the setting of the StandbyArchiveLocation and AlternateLocation properties.

4.4.4 Setting a Dependent Standby Database

You can use the Dependency property to set up a standby database whose incoming archived redo log files depends on another standby database or on the primary database. This is useful when two standby databases are on the same system (for example, one physical and one logical standby database). This is also useful if the standby database is on the same system as the primary database, in which case one standby database can share the log files with the other database on the same system, and there is no need to archive the log files separately to this standby database.

For example, if you want standby Database B to depend on another Database A (either a standby database or the primary database), you can set the Dependency property of standby Database B to be the database object name (same as its DB_UNIQUE_NAME initialization parameter) of Database A. The broker sets up redo transport services properly through the DEPENDENCY attribute of the LOG_ARCHIVE_DEST_n initialization parameter.

See Also:
Oracle Data Guard Concepts and Administration for more details on redo transport dependency.

4.4.5 Other Redo Transport Settings

You can use properties Binding, MaxFailure, MaxConnections, NetTimeout, and ReopenSecs to tune the performance of redo transport services and to set up redo transport services failure policies. These properties correspond to attributes on the LOG_ARCHIVE_DEST_n initialization parameter.

When creating a new standby database, the broker sets these properties with the default values. When importing an existing standby database, the broker imports existing settings corresponding to these properties if the broker finds a match between the service string of a current destination and the initial connect identifier. Note that the connect identifier is supplied when you import the standby database.

For most cases, the default values or the imported values should be sufficient for normal operations. If for some reason you need to change these property values, you can use DGMGRL commands to set up these properties. Enterprise Manager does not provide an interface for modifying these properties.

See Also:
See Chapter 9 for complete information about these properties

4.4.6 Managing Connections to the Standby Databases for Redo Transport Services

The broker automatically manages the Oracle Net connections used by redo transport services to the standby databases. Redo transport services managed by the broker do not rely on any Oracle Net Services naming method.

The broker constructs the connect descriptor to the standby apply instance and uses it as the value of the SERVICE attribute of the LOG_ARCHIVE_DEST_n initialization parameter. The broker uses the following information to construct the connect descriptor:

- The LOCAL_LISTENER initialization parameter of the standby apply instance

- The DB_UNIQUE_NAME initialization parameter of the standby database

- The INSTANCE_NAME parameter of the standby apply instance from V$INSTANCE

On the standby database, the broker registers a special service name db_unique_name_XPT with the standby listeners for redo transport services. On the primary database, the broker extracts the listener address from the LOCAL_LISTENER initialization parameter, and uses the service name db_unique_name_XPT and the value of INSTANCE_NAME to construct the connect descriptor so that redo transport services transmit archived redo log files to the standby apply instance.

Note:
If you are using a nondefault port number (for example, something other than port 1521) you need to ensure that the LOCAL_LISTENER initialization parameter for each standby instance resolves to an address that is reachable by all members of the configuration. Also, the DB_UNIQUE_NAME initialization parameter of the standby database matches the name that you provide when you add the standby database into the broker configuration.

4.4.7 Redo Transport Services in a RAC Database Environment

If your database is a RAC database, the broker sets up redo transport services in the following manner:

- If the primary database is a RAC database, the broker ensures that redo transport services are identical on each of the primary database instances. Each instance has the same remote destinations, and for each remote destination, all instances are set up the same in terms of redo transport service, performance related settings, and so on. If an instance has different settings, the broker raises a health check warning on that particular instance.

- If the standby database is a RAC database, only the apply instance receives log files from the primary database. If the primary database is also a RAC database, all instances of the primary database transmit log files to the same apply instance on the standby database. If the apply service is moved to a different standby instance either by the user or by the broker, the broker resets redo transport services on the primary database to transmit log files to the new apply instance. See Section 4.5 for more details.

Settings relative to redo transport services are saved in the broker configuration file as properties. When you update a log transport-related property on a standby database, the corresponding change is also made automatically by the broker to the LOG_ARCHIVE_DEST_n initialization parameter on all of the primary database instances. If a new instance comes up on the primary database, the broker sets up redo transport services for the new instance using the log transport-related properties of all the standby databases currently being managed by the broker. After the new instance is opened for activity, all archived redo log files generated on this instance will begin to transmit to the standby databases.

See also:
Oracle Data Guard Concepts and Administration for additional information about the LOG_ARCHIVE_DEST_n initialization parameter

4.5 Managing Log Apply Services

You can manage Redo Apply and SQL Apply on physical and logical standby databases through the following log apply-related configurable properties:

- Properties common to Redo Apply and SQL Apply

- ApplyInstanceTimeout

- DelayMins

- PreferredApplyInstance

- Properties specific to Redo Apply

- ApplyParallel

- Properties specific to SQL Apply

- LsbyASkipTxnCfgPr

- LsbyDSkipTxnCfgPr

- LsbyASkipCfgPr

- LsbyDSkipCfgPr

- LsbyASkipErrorCfgPr

- LsbyDSkipErrorCfgPr

- LsbyMaxEventsRecorded

- LsbyTxnConsistency

- LsbyRecordSkipErrors

- LsbyRecordSkipDdl

- LsbyRecordAppliedDdl

- LsbyMaxSga

- LsbyMaxServers

4.5.1 Managing Delayed Apply

You can set up log apply services so that the application of redo to the standby database is delayed. This allows the standby database to lag behind the primary database, and if a user error (for example, dropping a table) occurs during this window of time, the standby database will still contain the correct data that can be transmitted back to the primary database to repair the data.By default, a delay is not configured for a standby database. The broker applies redo data on the standby database as soon as it is received from the primary database. If the standby database has standby redo logs configured, the broker will enable real-time apply. When Redo Apply and SQL Apply apply redo in real time, the redo data is recovered directly from the standby redo log files as they are being filled. This means that the standby database does not have to wait for the log files to be archived before applying redo data from the archived redo log files. This allows the standby database to more easily stay transactionally consistent with the primary database.Use the DelayMins property to specify the number of minutes that log apply services must wait before applying redo data to the standby database. Note that only log apply services on the standby database are delayed. Redo transport services on the primary database are not delayed, thus the primary database data is still well protected by the standby database.

Caution:
Because the broker automatically enables real-time apply on standby databases that have standby redo logs configured, Oracle recommends that you configure all databases to use Flashback Database.

4.5.2 Managing Parallel Apply with Redo Apply

For Redo Apply, you can configure whether multiple parallel processes are used to apply redo data received from the primary database by using the ApplyParallel property. Parallelism is enabled by default, which means Redo Apply automatically chooses the optimal number of parallel processes based on the number of CPUs in the system. (This is equivalent to setting the ApplyParallel property to AUTO.) You can disable parallelism by setting the ApplyParallel property to NO.

Note:
The ApplyParallel property is not displayed on the Edit Properties page of Enterprise Manager.

See Also:
Section 9.2.3, "ApplyParallel"

4.5.3 Allocating Resources to SQL Apply

You can control how much SGA memory is available for SQL Apply. This can be set using the LsbyMaxSga property.

To control the number of parallel query servers used by SQL Apply, you can use the LsbyMaxServers property.

Users can control the trade off between SQL Apply performance and transaction consistency level. For a higher transaction consistency level, SQL Apply will have a higher performance impact. To control the transaction consistency level, use the LsbyTxnConsistency property.

See Also:
Section 9.2.28, "LsbyMaxSga" and Section 9.2.29, "LsbyMaxServers"

Changing any property pertaining to SQL Apply will result in restarting SQL Apply if the current database state is ONLINE (for example, SQL Apply is currently running). If the current database state is LOG-APPLY-OFF, the property changes will take effect the next time the database state is changed to ONLINE.

4.5.4 Managing SQL Apply Filtering

One of the benefits of a logical standby database is to allow control of what to apply and what not to apply. This is done by setting up SQL Apply filters. The granularity of the filtering ranges from a specific transaction to database objects to a particular class of SQL statement on a particular schema.

To add a SQL Apply filter in Data Guard broker, use the LsbyASkip* properties (for example, LsbyASkipTxnCfgPr or LsbyASkipCfgPr). To delete a previously added SQL Apply filter, use the LsbyDSkip* properties (for example, LsbyDSkipTxnCfgPr or LsbyDSkipCfgPr).

See Also:
Chapter 9 for information on these properties

Changing these properties results in restarting SQL Apply if the current database state is ONLINE. If the current database state is LOG-APPLY-OFF, the property changes take effect the next time the database state is changed to ONLINE.

4.5.5 Managing SQL Apply Error Handling

You can fine-tune SQL Apply to handle apply errors on a specified set of SQL statements on particular schemas. When such SQL Apply errors are encountered, Data Guard can either skip the error to continue SQL Apply or call a specified stored procedure at the time when the error is encountered.

To add this error handling capability, use the LsbyASkipErrorCfgPr property. To delete a previously added error handling specification, use the LsbyDSkipErrorCfgPr property.

Changing these properties results in restarting SQL Apply if the current database state is ONLINE. If the current database state is LOG-APPLY-OFF, the property changes take effect the next time the database state is changed to ONLINE.

4.5.6 Managing the DBA_LOGSTDBY_EVENTS Table

The DBA_LOGSTDBY_EVENTS table records important events that affect SQL Apply. Because every logical standby database might have a different interest in the set of events to be recorded in this table, Data Guard provides a means to control the event recording. From the Data Guard broker, you can use the LsbyRecord* properties (for example, LsbyRecordSkipDdl or LsbyRecordSkipErrors) to control recording of a particular set of events. The value of these properties are either TRUE or FALSE, indicating the turning on or off of the event recording.

If the current database state is ONLINE, changing these properties stops and restarts SQL Apply. If the current database state is LOG-APPLY-OFF, the property changes take effect the next time the database state is changed to ONLINE.

4.5.7 Log Apply Services in a RAC Database Environment

If a standby database is a RAC database, only one instance of the RAC database can have log apply services running at any time. This instance is called the apply instance. If the apply instance fails, the broker automatically moves log apply services to a different instance; this is called apply instance failover. In order for the apply instance to continuously apply archived redo log files received from the primary database, the broker also manages redo transport services such that the archived redo log files generated on the primary database are always transmitted to the apply instance.

4.5.7.1 Selecting the Apply Instance

If you have no preference which instance is to be the apply instance in a RAC standby database, the broker randomly picks an apply instance. If you want to select a particular instance as the apply instance, there are two methods to do this.

- The first method is to pick an apply instance before there is an apply instance running in the RAC standby database. To do so, set the value of the PreferredApplyInstance property to the name of the instance (SID) you prefer to be the apply instance. The broker starts log apply services on the instance specified by the PreferredApplyInstance property when no apply instance is yet selected in the RAC standby database. This could be the case before you enable the standby database for the first time, or if the apply instance just failed and the broker is about to do an apply instance failover, or if the RAC database is currently the primary and you want to specify its apply instance in preparation for a switchover. Once the apply instance is selected and, as long as the apply instance is still running, the broker disregards the value of the PreferredApplyInstance property even if you change it.

- The second method is to change the apply instance when the apply instance is already selected and is running. To change the apply instance, issue the DGMGRL SET STATE command to set the standby database state to ONLINE, with a specific apply instance argument. The SET STATE command will update the PreferredApplyInstance property to the new apply instance value, and then move log apply services to the new instance. For example, use DGMGRL SHOW command to show the available instances for the standby database, then issue the EDIT DATABASE command to move log apply services to the new instance:

DGMGRL> SHOW DATABASE 'DR_Sales' ;
Database
Name:            DR_Sales
Role:            PHYSICAL STANDBY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
dr_sales1 (apply instance)
dr_sales2

Current status for "DR_Sales":
SUCCESS

DGMGRL> EDIT DATABASE 'DR_Sales' SET STATE='ONLINE' WITH APPLY
INSTANCE="dr_sales2';
Succeeded.
DGMGRL> SHOW DATABASE 'DR_Sales' 'PreferredApplyInstance';
PreferredApplyInstance = 'dr_sales2'

DGMGRL> SHOW DATABASE 'DR_Sales' ;
Database
Name:            DR_Sales
Role:            PHYSICAL STANDBY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
dr_sales1
dr_sales2 (apply instance)

Current status for "DR_Sales":
SUCCESS

Ensure that the new apply instance is running when the command is issued. Otherwise, the apply instance remains the same.

Once the apply instance is selected, the broker keeps apply instance information in the broker configuration file so that even if the standby database is shut down and restarted, the broker still selects the same instance to start log apply services. The apply instance remains unchanged until changed by the user or it fails for any reason and the broker decides to do an apply instance failover.

4.5.7.2 Apply Instance Failover

When the apply instance fails, not only do log apply services stop applying log files to the standby database, but redo transport services stop transmitting redo data to the standby database because the apply instance is not available to receive and store archived redo log files locally 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. The apply instance failover capability provided by the broker enhances data protection.

To set up apply instance failover, set the ApplyInstanceTimeout property to specify the time period that the broker will wait after detecting an apply instance failure and before initiating an apply instance failover. To select an appropriate timeout value, you need to 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 associated with moving the log apply services to a different instance. The overhead may include retransmitting, from the primary database, all log files accumulated on the failed apply instance that have not been applied if those log files are not saved in a shared file system that can be accessed from other standby instances.

The broker default value of the ApplyInstanceTimeout property is 0 seconds, indicating that apply instance failover should occur immediately upon detection of the failure of the current apply instance.

After the broker initiates an apply instance failover, the broker selects a new apply instance according to the following rule: if the PreferredApplyInstance property indicates an instance that is currently running, select it as the new apply instance; else pick a random instance that is currently running to be the new apply instance. The broker also resets redo transport services so that the primary database starts transmitting redo data to the new apply instance.

4.6 Managing Data Protection Modes

The broker can simplify the process of setting up your configuration for any of the different grades of data protection: maximum protection, maximum availability, or maximum performance.

This section contains the following topics to help you configure the proper protection for your configuration:

- Section 4.6.1, "Setting the Protection Mode for Your Configuration"

- Section 4.6.2, "How the Protection Modes Influence Broker Operations"

4.6.1 Setting the Protection Mode for Your Configuration

To set the protection mode, perform the following steps:

Step 1   Determine which data protection mode you want to use.

Each data protection mode provides a different balance of data protection, data availability, and database performance. To select the data protection mode that meets the needs of your business, carefully consider your data protection requirements and the performance expectations of your users.

Maximum Protection This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and to 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. This protection mode is not used if you enable fast-start failover.

Maximum Availability This protection mode provides the highest level of data protection that is possible 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 ensures 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.

This protection mode is required if you enable fast-start failover.

Maximum Performance This protection mode is the default 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. The primary database's redo data stream is also written to at least one standby database, but the redo stream is written asynchronously with respect to the commitment of the transactions that create the redo data. This protection mode is not used if you enable fast-start failover.

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 protection and maximum availability modes require that a standby redo log is configured on at least one standby database in the configuration. All three protection modes require that specific log transport attributes be specified on the LOG_ARCHIVE_DEST_n initialization parameter to send redo data to at least one standby database.

See Also:
Oracle Data Guard Concepts and Administration for complete information about the data protection modes

Step 2   Set up standby redo log files.

If you are configuring the maximum protection or maximum availability level of protection, you must add standby redo log files on all standby databases. Also, Oracle recommends you add standby redo log files on the primary database in preparation for a future switchover or failover. Standby redo log files are required on the primary database if you want the broker to automatically reinstate the old (failed) primary database after a fast-start failover. (See Section 5.5.7 for more information about reinstatement.)

Enterprise Manager automatically prompts you to select one or more standby databases in the configuration and sets up standby redo log (SRL) files on them and on the primary database in preparation for a future switchover.

See Also:
If you are using the DGMGRL command-line interface, follow the instructions in Oracle Data Guard Concepts and Administration to configure standby redo log files. Also, see Section 6.5.3 for additional information about changing the database protection mode.

Step 3   Set the LogXptMode property, if necessary.

If the data protection mode requires that you change the redo transport service used by any of the standby databases, change the setting of the LogXptMode database property appropriately on each standby database. See Section 4.4 for more information about setting the redo transport service. Table 4-2 shows the protection modes and the corresponding redo transport service.

Enterprise Manager automatically specifies the correct redo transport service on the primary database in preparation for a future switchover. See Section 6.5.3 for additional information about changing the database protection mode.

Table 4-2 Data Guard Protection Modes and Requirements

Protection Mode

Redo Transport

Standby Redo Log Files Needed?

Used with Fast-Start Failover?

MAXPROTECTION

SYNC

Yes

No

MAXAVAILABILITY

SYNC

Yes

Yes

MAXPERFORMANCE

ASYNC or ARCH

Yes for ASYNC

No

Step 4   Set the protection mode.

Set the protection mode using DGMGRL commands or Enterprise Manager.

With DGMGRL:

1. If you plan to set the protection mode to either the MAXPROTECTION or MAXAVAILABILITY, ensure that standby redo log files are configured on the standby database. Do this also 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 (property) command and specify the standby database whose redo transport service should be changed to correspond to the protection mode you plan to set. For example, if you plan to set the overall Data Guard configuration to the MAXAVAILABILITY mode, you must use the EDIT DATABASE command to set the SYNC mode for redo transport services. For example:

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC';

Do this also 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 protection-mode command to set the overall configuration protection mode. For example:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

See Section 7.5 for a DGMGRL scenario showing how to set the protection mode.

With Enterprise Manager:

1. On the Data Guard overview page, click the link to the right of the Protection Mode label.

2. Select Maximum Protection, Maximum Availability, or Maximum Performance and click Continue.

3. If prompted, log in to the database with SYSDBA privileges and click Login.

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

5. On the Confirmation page, click Yes.

See Section 6.5.3 for a scenario showing how to set the protection mode.

After you upgrade the protection mode using either DGMGRL or Enterprise Manager, the primary database will be restarted automatically. The primary database need not be restarted following a downgrade of the protection mode.

4.6.2 How the Protection Modes Influence Broker Operations

This section describes how operations such as switchover, failover, disabling, or enabling the Data Guard configuration can have an effect on the configuration's protection mode and redo transport services. This section contains the following sections:

- Upgrading or Downgrading the Current Protection Mode

- Switchover Operations

- Failover Operations

- Disable and Enable Operations

- Requirements For Removing a Database from the Configuration

- Requirements On Other Operations

4.6.2.1 Upgrading or Downgrading the Current Protection Mode

When you upgrade the current Data Guard protection mode (for example, to upgrade from the maximum performance mode to the maximum availability mode), the broker shuts down and restarts the primary database. When you downgrade the current Data Guard protection mode, the database does not need to be restarted. Follow these recommendations when upgrading or downgrading the Data Guard protection mode:

- When upgrading the protection mode, upgrade the redo transport service before you upgrade the overall protection mode. (Enterprise Manager does this for you. See Section 6.5.3 for information.) At the time when you change the protection mode or reset the redo transport service of a standby database, the broker verifies that there is at least one standby database in the configuration that can support the requested grade of protection. If not, then the broker does not change the protection mode and returns an error.

- When downgrading the protection mode, downgrade the protection mode first and then change the redo transport service (if necessary). The broker will not allow changing the redo transport service if doing so invalidates the current overall protection mode.

If you upgrade the protection mode from the maximum performance mode, the broker ensures that there is at least one standby database using standby redo log files, and whose redo transport service is set to SYNC. Additionally, for upgrades to MAXPROTECTION, the broker ensures there are no gaps in log files on the standby database. If there are no standby databases in the configuration that meet these requirements, the request to upgrade the protection mode is rejected with an error.

The protection mode cannot be changed if fast-start failover is enabled.

WARNING:

The primary database will be shut down and restarted if you upgrade the protection mode.

4.6.2.2 Switchover Operations

A switchover does not change the overall Data Guard protection mode. The protection mode remains the same as it was before the switchover.

This requires that there be a standby database that is properly configured to support the current protection mode once the switchover completes. This can be either another standby database in the configuration or the current primary database that will become a standby database after the switchover completes.

Before you invoke a switchover, if necessary, you can add standby redo log files and set the redo transport service on the current primary database, or on another standby database in the configuration, to the SYNC, ASYNC, or ARCH mode that is required to support the Data Guard protection mode. Then, when the switchover begins:

- The broker verifies the presence of standby redo log files and the redo transport service setting on each standby database and on the current primary database.

- The broker verifies there are no gaps if the protection mode is set to MAXPROTECTION.

If the verification is successful, the switchover continues; otherwise, the switchover fails, and the database roles and the broker configuration files remain unchanged.

WARNING:

The broker will shut down and restart the primary database if the target of the switchover is a physical standby database.

See Also:
Section 5.3 for more information about switchovers

4.6.2.3 Failover Operations

After you perform a manual failover, the Data Guard protection mode is downgraded to maximum performance mode if the protection mode was at maximum protection. You can upgrade the protection mode later, if necessary. If the protection mode was at maximum availability, it remains at maximum availability. The redo transport services of the standby databases remain unchanged.

If fast-start failover occurs, the broker preserves the protection mode at the same maximum availability level in which it was operating before the failover.

See Also:
Section 5.4 and Section 5.5 for more information about manual failover and fast-start failover, respectively

4.6.2.4 Disable and Enable Operations

When you disable broker management of a standby database, the broker checks to see if the overall protection mode can still be satisfied by any of the remaining standby databases. If not, the broker rejects the disable operation. Otherwise, the broker allows the disable operation to proceed as long as fast-start failover is not enabled. If it is enabled, the broker allows the disable operation to proceed only if the standby database is not the target standby database for fast-start failovers.

Caution:

If you disable broker management of a standby database in the broker configuration, that standby database cannot be used by the broker as a failover target in the event of loss of the primary database.

After a standby database is successfully disabled, you can change the redo transport service for that database and the broker will record the change in the broker configuration file. The change will not affect the overall protection mode because it is guaranteed that at least one of the enabled standby databases already satisfies the overall protection mode requirement.

As long as fast-start failover is not enabled, you can disable the entire configuration regardless of the protection mode. This is because you may want to use the broker only to set up a Data Guard configuration, and then disable it from the broker's control and use other interfaces (for example, using SQL*Plus and SQL statements) for management. You cannot disable the configuration if fast-start failover is enabled. See Section 5.5.2.2, "Restrictions When Fast-Start Failover is Enabled" for more information.

If the entire configuration is disabled, you can change any broker settings, including the redo transport services of the standby databases and the protection mode of the configuration. The broker saves the changes in the broker configuration file, but the changes will not be made to the database itself.

When enabling broker management of the entire configuration, the broker first checks to see if the protection mode will be satisfied by the redo transport services of the standby databases that will be enabled. If not, the enable operation fails and the configuration remains disabled. Otherwise, the enable operation successfully enables the configuration, and the broker enables the database using the settings saved in the broker configuration file.

4.6.2.5 Requirements For Removing a Database from the Configuration

When removing a standby database from the broker configuration, the broker checks to see if the protection mode will still be satisfied. The broker quits the operation if:

- Removing the database compromises the protection mode

- Fast-start failover is enabled and you try to remove the standby database that is the target of the fast-start failover

If you want to remove the entire configuration, the broker always allows the operation.

4.6.2.6 Requirements On Other Operations

Some operations that take place in a broker configuration, especially operations related to redo transport services, can affect the overall protection mode. These operations include:

- Setting the standby database to the offline state

- Stopping redo transport services on the primary database

- Stopping redo transport services to individual standby databases

Before any of these operations can proceed, the broker checks to see if the protection mode will be supported by the redo transport service settings on the standby databases after the operation completes. If not, the broker quits the operation and returns an error.

4.7 Database Status

Database status reveals the health of the database. In general, the broker checks the health of a database by verifying if the actual database state and settings match with those described in the broker configuration file. This is done by checking if any component of the Data Guard configuration is functioning incorrectly (for example, if redo transport services have an error), and by checking if other required database settings are correctly set (for example, if the server parameter files are available and if the ARCHIVELOG mode is turned on). The following is a detailed list of what is being checked by the broker on a primary database and a standby database.

On a primary database, the health check determines whether the following conditions are met:

- Database is in the state specified by the user, as recorded in the broker configuration file.

- Database is in the correct data protection mode.

- Database is using a server parameter file.

- Database is in the ARCHIVELOG mode.

- Database guard is turned off.

- Supplemental logging is turned on when there is a logical standby database in the configuration.

- Redo transport services do not have any errors.

- Database settings match those specified by the broker configurable properties.

- Redo transport settings match those specified by the redo transport-related properties of the standby databases.

On a standby database, the health check determines whether the following conditions are met:

- Database is in the state specified by the user, as recorded in the broker configuration file.

- Database is using a server parameter file.

- Database settings match those specified by the broker configurable properties.

- Database guard is turned on when the database is a logical standby database.

- Primary and target standby databases are synchronized if fast-start failover is enabled.

The following monitorable properties can be used to query the database status:

- StatusReport

- LogXptStatus

- InconsistentProperties

- InconsistentLogXptProps

Note:
These properties are directly accessed through the DGMGRL command-line interface. Enterprise Manager rearranges the values of these properties for presentation in the GUI.

The StatusReport property provides a list of all health check problems the broker detected during a health check. This is usually the first property you use to check the database status. In the following example, you see three items reported by the StatusReport property.

DGMGRL> SHOW DATABASE 'North_Sales' 'StatusReport';
STATUS REPORT
INSTANCE_NAME   SEVERITY ERROR_TEXT
sales1      ERROR ORA-16737: the redo transport service for standby "North_Sales" has an error
sales2      ERROR ORA-16737: the redo transport service for standby "North_Sales" has an error
sales2      WARNING ORA-16715: log transport related property MaxFailure of standby "North_Sales" is inconsistent

To further check the details about the database status, you can use the LogXptStatus, InconsistentProperties, and InconsistentLogXptProps properties. LogXptStatus lists all log transport errors detected on all instances of the primary database. InconsistentProperties lists all properties that have inconsistent values between the broker configuration file and the database settings. InconsistentLogXptProps lists all redo transport-related properties of standby databases that have inconsistent values between the broker configuration file and the redo transport settings. For example, the output of StatusReport (in the previous example) shows two problems: some redo transport services errors and an inconsistent redo transport-related property.

Issue the following SHOW DATABASE commands to obtain further details about the problems.

DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus';
REDO TRANSPORT STATUS
PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME  STATUS
sales1                DR_Sales               ORA-12514: TNS:listener could not resolve SERVICE_NAME
given in connect descriptor
sales2                DR_Sales               ORA-12514: TNS:listener could not resolve SERVICE_NAME
given in connect descriptor

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';
INCONSISTENT REDO TRANSPORT PROPERTIES
INSTANCE_NAME         STANDBY_NAME        PROPERTY_NAME         MEMORY_VALUE       BROKER_VALUE
sales2            DR_Sales           MaxFailure                     9                  0

See Also:
Chapter 9 for detailed information about database properties

5 Switchover and Failover Operations

This chapter describes how the broker manages databases during switchover and failover. This chapter contains the following sections:

- Section 5.1, "Overview of Switchover and Failover in a Broker Environment"

- Section 5.2, "Choosing a Target Standby Database"

- Section 5.3, "Switchover"

- Section 5.4, "Manual Failover"

- Section 5.5, "Fast-Start Failover"

5.1 Overview of Switchover and Failover in a Broker Environment

An Oracle database operates in one of two roles: primary or standby. Data Guard helps you change the role of a database using either a switchover or a failover:

- A switchover is a role reversal between the primary database and one of its standby databases. A switchover guarantees no data loss. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role. The transition occurs without having to reenable either database.

- A failover is when the primary database (all instances of a RAC primary database) fails and one of the standby databases is transitioned to take over the primary role. Failover is performed only in the event of a catastrophic failure of the primary database, and there is no possibility of recovering the primary database in a timely manner. Failover may or may not result in data loss depending on the protection mode in effect at the time of the failover.

Without the broker, you perform role transitions by first determining if a role transition is necessary and then issuing a series of SQL statements (as described in Oracle Data Guard Concepts and Administration). The broker simplifies switchovers and failovers by allowing you to invoke them using a single key click in Oracle Enterprise Manager or a single command in the DGMGRL command-line interface (referred to in this documentation as manual failover). Moreover, 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 allows you to increase availability with less need for manual intervention, thereby reducing management costs. Manual failover gives you control over exactly when a failover occurs and to which target standby database. Regardless of the method you choose, the broker coordinates the role transition on all databases in the configuration.

When the database is opened for the first time after a role transition, the DB_ROLE_CHANGE system event fires. You can write a trigger that's associated with this system event to manage tasks after a role change occurs. See the table of system manager events in Oracle Database Application Developer's Guide - Fundamentals for more details.

5.2 Choosing a Target Standby Database

There are many factors to take into consideration when selecting a standby database to be the next primary database after a switchover or a failover. You need to consider all of the options at the time you are building your Data Guard configuration, including factors such as the characteristics of physical standby databases versus logical standby databases, the network latency to your standby database sites, the computing capabilities at a future primary database site, and so on.

For switchovers, understanding all of the factors can simplify the choice of which standby database to consider as your new primary database. In disaster situations where a failover is necessary, you may be more limited in which standby database is the best one to pick up the failed primary database's activities. The following sections provide guidelines to help you choose a target standby database.

Note:
For fast-start failover, you must pre-select the target standby database that will be used. Section 5.5 provides more information about fast-start failover.

5.2.1 Choosing a Target Standby Database for Switchover

When performing a switchover in a configuration whose standby databases are all of the same type (all physical or all logical standby databases), choose the standby database that has the least amount of unapplied redo. By choosing the standby database with the least amount of unapplied redo, you can minimize the overall time it takes to complete the switchover operation. For example:

- Using DGMGRL, you can do this by examining the RecvQEntries monitorable property of each standby database in the configuration. For example, connect to one of the standby databases in the configuration and issue the SHOW DATABASE database_name RecvQEntries command. (When real-time apply is enabled and keeping up, this property will return no rows.)

- Using Enterprise Manager, you can view the value of the ApplyLag column for each standby database in the Standby Databases section of the Data Guard Overview Page.

If the configuration contains both physical and logical standby databases, consider choosing a physical standby database (that has the least amount of unapplied redo) to be the target standby database. A switchover to a physical standby database is preferable because all databases in the configuration will be available as standby databases to the new primary database after the switchover operation completes. Whereas a switchover to a logical standby database will invalidate and disable the physical standby databases in the configuration. You will then need to reenable the physical standby databases from a backup of the new primary database before you can reenable them.

Note:
If the Data Guard configuration is running in maximum protection mode, the broker does not allow a switchover to occur to a logical standby database.

5.2.2 Choosing a Target Standby Database for Failover

When performing a failover in a configuration that contains all physical standby databases or all logical standby databases, choose the standby database that has the most data archived to it. By choosing the standby database that has the most amount of redo data archived to it, you can minimize the amount of data loss and in some cases, incur no data loss at all.

If the configuration contains both physical and logical standby databases, consider choosing a physical standby database as the target standby database. A failover to a physical standby database is preferable because it is likely that all standby databases in the configuration will still be available as standby databases to the new primary database after the failover operation completes. A failover to a logical standby database requires that all other standby databases be reenabled from a copy of the new primary database after the failover completes. In addition, a logical standby database may contain only a subset of the data present in the primary database. (For example, if the DBMS_LOGSTDBY.SKIP procedure was used to specify which database operations done on the primary database will not be applied to the logical standby database.)

However, there may be exceptions to the recommendation to choose a physical standby database as the target standby database. For example, if the physical standby database is lagging behind the logical standby database (the physical standby database was in read-only mode or running with a log apply delay via the DelayMins property) and your business requires minimum downtime, consider selecting the logical standby database as the failover target.

5.3 Switchover

You can switch a database from the primary role to the standby role, as well as from standby to primary. This is known as a database switchover, because the standby database that you specify becomes the primary database, and the original primary database becomes a standby database. There is no loss of data, the data is consistent between the original primary database and the new primary database after the switchover completes.

Whenever possible, you should switch over to a physical standby database:

- If the switchover transitions a physical standby database to the primary role, then:

- The original primary database will be switched to a physical standby role.

- The online redo log files will be continuously archived from the new primary database to all standby databases in the configuration.

- Both the primary database and the target standby database will be restarted as a part of the switchover operation.

Standby databases not involved in the switchover will continue operating in the state they were in before the switchover occurred and will automatically begin applying archived redo log files from the new primary database.

- If the switchover transitions a logical standby database to the primary role, then:

- The original primary database will be switched to a logical standby role.

- Neither the primary database nor the logical standby database needs to be restarted after the switchover completes.

Other logical standby databases in the broker configuration that were not involved in the switchover will remain viable after the switchover. There is no need to restart any databases.

Switchover to a logical standby database is disallowed when the configuration is running in maximum protection mode.

Warning:

Switching over to a logical standby database results in the physical standby databases in the broker configuration being disabled by the broker, making these databases no longer viable as standby databases. Section 5.4.3 describes how to restore their viability as standby databases.

5.3.1 Before You Perform a Switchover Operation

Consider the following points before you begin a switchover:

- When you start a switchover, the broker verifies that at least one standby database, including the primary database that is about to be transitioned to the standby role, is configured to support the overall protection mode (maximum protection, maximum availability, or maximum performance).

- Prepare the primary database in advance for its possible future role as a standby database in the context of the overall protection mode (see Section 4.6). Such preparation includes:

- Ensuring that standby redo log files are configured on the primary database if you intend to use SYNC or ASYNC redo transport service to the database after the switchover.

- Presetting redo transport services related properties, such as LogXptMode, NetTimeout, StandbyArchiveLocation, and AlternateLocation. For more details about managing redo transport services using configurable properties, see Section 4.4.

- Presetting log apply services related properties, such as DelayMins and ApplyParallel. For more details about managing log apply services using configurable properties, see Section 4.5.

- For each temporary table, verifying that temporary files associated with that table on the primary database also exist on the standby database. See Oracle Data Guard Concepts and Administration for more information about temporary files.

Note that the broker does not use the properties to set up redo transport services and log apply services until you actually switch over the primary database to the standby role. Thus, the validity of the values of these properties is not verified until after the switchover. Once you set these properties, their values persist through role changes during switchover and failover.

- If fast-start failover is enabled, a switchover can be performed only to the pre-specified target standby database and only if the standby database is synchronized with the primary database. For information about enabling fast-start failover and starting the observer, see Section 5.5.2.

After a switchover completes, the broker preserves the overall Data Guard protection mode as part of the switchover process by keeping the protection mode at the same protection level (maximum protection, maximum availability, or maximum performance) it was at before the switchover. Also, the network transmission mode (SYNC, ASYNC, or ARCH) for transporting redo to other standby databases not involved in the switchover does not change after a switchover. Log apply services on all other standby databases not involved in the switchover automatically begin applying archived redo log files from the new primary database.

If there are both logical and physical standby databases in the configuration and the switchover occurs to a logical standby database, you need to reenable all physical standby databases, as described in Section 5.4.3.

5.3.2 Starting a Switchover

The act of switching roles should be a well-planned activity. The primary and standby databases involved in the switchover should have as small a transactional lag as possible. Oracle Data Guard Concepts and Administration provides information about setting up the databases in preparation of a switchover.

To start a switchover using Enterprise Manager, select the standby database that you want to change to the primary role and click Switchover. When using DGMGRL, you need to issue only one SWITCHOVER command to specify the name of the standby database that you want to change into the primary role.

The broker controls the rest of the switchover, as described in Section 5.3.3.

5.3.3 How the Broker Performs a Switchover

Once you start the switchover, the broker:

1. Verifies that the primary and the target standby databases are in the following states:

a. The primary database is enabled and is in the ONLINE state.

b. The participating standby database is enabled and is in the ONLINE state.

The broker allows the switchover to proceed as long as there are no errors for the primary database and the standby database that you selected to participate in the switchover operation. Errors occurring for any other standby databases not involved in the switchover will not impede the switchover.

2. Shuts down all instances except one.
If the primary database is a RAC database, the broker keeps only one instance running and shuts down all other instances before it continues the switchover. If the standby database you want to switch to the primary role is a RAC database, the broker shuts down all instances except the apply instance before it continues the switchover. If those other instances cannot be shut down, the switchover fails. In this case, you must manually shut down those other instances and issue the switchover command again. It is also important that you do not start any new instances during the switchover. If you must manually shut down the instances on the standby database, do not shut down the apply instance.

3. Switches roles between the primary and standby databases.
The broker first converts the original primary database to run in the standby role. Then, the broker transitions the target standby database to the primary role. If any errors occur during either conversion, the broker stops the switchover. See Section 10.3, "Troubleshooting Problems During a Switchover Operation" for more information.

4. Updates the broker configuration file to record the change in roles.
Because the configuration file profiles all database objects in the configuration, this ensures that each database will run in the correct role should it be restarted later for any reason.

5. Restarts the new standby (former primary) database if the switchover occurs with a physical standby database, and Redo Apply begins applying redo data from the new primary database. If this is a RAC database, the broker restarts the instances that it shut down prior to the switchover.

6. Restarts the new primary database if it was a physical standby database, opens it in read/write mode, and starts redo transport services transmitting redo data to the standby databases, including to the former primary database. If the switchover occurs to a logical standby database, there is no need to restart any databases. If this is a RAC database, the broker restarts the instances that it shut down prior to the switchover.

The broker verifies the state and status of the databases to ensure that the switchover transitioned the databases to their new role correctly. Standby databases not involved in the switchover and not disabled by the broker after the switchover will continue operating in the state they were in before the switchover. For example, if a physical standby database was in read-only mode, it will remain in that mode after switchover completes. Redo Apply and SQL Apply on all other standby databases not involved in the switchover automatically begin applying archived redo log files from the new primary database.

5.4 Manual Failover

You can convert a standby database to a primary database when the original primary database fails and there is no possibility of recovering the primary database in a timely manner. This is known as a manual failover. There may or may not be data loss depending upon whether your primary and target standby databases were transactionally consistent at the time of the primary database failure. The word manual is used to contrast this type of failover with a fast-start failover (described in Section 5.5).

Note:
You can perform a manual failover even if fast-start failover is enabled. See Section 5.5.2.4 for more information.

The following sections describe how to perform manual failovers:

- Section 5.4.1, "Complete and Immediate Manual Failovers"

- Section 5.4.2, "Performing a Manual Failover Operation"

- Section 5.4.3, "Reenabling Disabled Databases After Failover or Switchover"

5.4.1 Complete and Immediate Manual Failovers

Using Enterprise Manager or DGMGRL, you can perform either a complete (recommended) or an immediate failover:

- A complete failover is the recommended and default failover option. It automatically recovers the maximum amount of data for the protection mode of the original primary database application data. A complete failover also attempts to bring along any standby databases not involved in the failover, to continue serving as standby databases to the new primary database.

The behavior of a complete failover varies depending on the type of standby database being used:

- After failover to a physical standby database, the original primary database must be reenabled to act as a standby database for the new primary database. In addition, some standby databases may be disabled by the broker during the failover if the broker detects that they have applied redo beyond where the new primary database had applied. Any database that was disabled by the broker must be reenabled using the steps described in Section 5.4.3.

- After failover to a logical standby database, the original primary database and all standby databases in the configuration (that were not the target of the failover) will be disabled and must be reenabled to act as standby databases for the new primary database. Any database that was disabled by the broker must be reenabled using the steps described in Section 5.4.3.

During a complete failover, the broker controls the failover steps described in Section 5.4.2.1.

- An immediate failover is the fastest type of failover. However, no additional data is applied on the standby database once you invoke the failover. Another consequence of immediate failover is that you must also reenable the original primary database and all other standby databases not involved in the failover before they can serve as standby databases to the new primary database. Section 5.4.3 describes how to do this. During an immediate failover, the broker controls the failover steps described in Section 5.4.2.2.

Caution:
Always try to perform a complete failover first. Only when a complete failover is unsuccessful should you perform an immediate failover. Depending on the destination attributes of redo transport services, a complete failover can occur without any data loss, while an immediate failover usually results in data loss.

5.4.2 Performing a Manual Failover Operation

After determining that there is no possibility of recovering the primary database in a timely manner, ensure that the primary database is shut down and then begin the failover operation.

The steps in this section describe how to perform a manual failover. Depending on the failover and the types of standby databases involved, some of the databases may need to be restarted or reenabled. The instructions guide you through the appropriate steps for each type of situation.

Step 1   Determine which of the available standby databases is the best target for the failover.

Follow the guidelines described in Section 5.2, "Choosing a Target Standby Database".

Step 2   Start the failover.

Using Enterprise Manager or DGMGRL, perform either a complete (recommended) or an immediate failover.

Manual Failover Using Enterprise Manager:

On the Data Guard Overview Page in Enterprise Manager, select the standby database that you want to change to the primary role and click Failover. Then, on the Failover Confirmation Page, click Yes to invoke the default Complete failover option.

See Also:
Section 6.7, "Scenario 7: Invoking a Failover Manually"

Manual Failover Using DGMGRL:

On the target standby database, issue the FAILOVER command to invoke a complete failover, specifying the name of the standby database that you want to change into the primary role:

DGMGRL> FAILOVER TO database-name;

See Also:
"Scenario 8: Performing a Manual Failover Operation" in Chapter 7 and the reference information for the FAILOVER command in Chapter 8

If the target standby database is a RAC database, the broker will shut down all instances except the apply instance before it continues the failover. If the broker cannot shut down the instances, the failover fails. In this case, you must manually shut down all instances except the apply instance and issue the FAILOVER command again. It is also important that you do not start any new instances during the failover. The broker restarts instances that it shut down prior to the failover.

Step 3   Reset the protection mode.

After a manual failover (complete or immediate), the overall Data Guard protection mode is handled as follows:

- If the protection mode was at maximum protection, it is reset to maximum performance. You can upgrade the protection mode later, if necessary, as described in Section 4.6.1.

- If the protection mode was at maximum availability, it remains at maximum availability.

Note:
If you perform a manual failover when fast-start failover is enabled:

- The failover can only be performed to the pre-selected target standby database.

- The broker preserves the protection mode at the maximum availability level (which is the mode it was operating in before the failover occurred).

Redo transport settings (SYNC, ASYNC, or ARCH) on standby databases other than the target standby database do not change.

Step 4   Re-establish a disaster-recovery configuration.

To maintain a viable disaster-recovery solution in the event of another disaster, you may need to perform the additional steps described in Section 5.4.3 to:

- Reinstate the original primary database to act as a standby database in the new configuration.

- Flash back (or reinstate) standby databases in the configuration that were disabled by the broker.

After a complete failover finishes, any standby database not involved in the failover that is not viable as a standby for the new primary database will be disabled by the broker. This can happen for either of these reasons:

- The broker detects that the standby database has applied redo data beyond what has been applied on the new primary database.

For instance, this could happen if a standby database not involved in the failover has applied more log files than the new primary database itself has applied. The standby database must be reenabled or flashed back before it can serve as a standby for the new primary database.

- The failover was to a logical standby database, the broker disables all of the (physical and logical) standby databases in the configuration that were not involved in the failover. They must be reenabled before they can serve as standby to the new primary database.

5.4.2.1 How the Broker Performs a Complete Failover Operation

Once you start a complete failover, the broker:

1. Checks to see if the primary database is still available and, if so, issues a warning message asking whether you want to continue with the failover operation. If you are using Enterprise Manager and choose to continue, the primary database is shut down.

2. Verifies that the target standby database is enabled. If the database is not enabled, you will not be able to perform a failover to this database. If the target is a RAC standby database, the broker shuts down all instances except the apply instance.

3. Waits for the target standby database to finish applying any remaining archived redo log files before stopping Redo Apply or SQL Apply.

4. Transitions the target standby database into the primary database role, as follows:

a. Opens the new primary database in read/write mode.

b. Determines whether or not any standby databases that did not participate in the failover operation have applied redo data beyond the new primary database, and thus need to be reenabled.
If a standby database not involved in the failover is not disabled by the broker during this failover, it will remain in the state it was in before the failover. For example, if a physical standby database was operating in read-only mode, it will remain in read-only mode.

c. Starts redo transport services to begin transmitting redo data to all standby databases not involved in the failover and not required to be reenabled.

Note:
Standby databases not directly involved in a failover may be disabled by the broker during the failover, and they must be reenabled in the configuration before they can serve as standby databases to the new primary database. If there is more than one standby database in the configuration, Oracle recommends configuring Flashback Database on every database so that if failover occurs to a physical standby database, you can more easily reinstate any disabled physical standby databases. However, if failover occurs to a logical standby database, all (physical and logical) standby databases will be disabled by the broker. In this case, Flashback Database cannot be used to reinstate databases.
To use Flashback Database, you must configure it on every database in the configuration. Then, after a failover occurs, you can use Flashback Database to reinstate your disabled physical standby database.

5. If the target is a RAC standby database, the broker restarts instances that it shut down prior to the failover.

The broker allows the failover to proceed as long as there are no errors for the standby database that you selected to participate in the failover. Errors occurring for any standby databases not involved in the failover will not stop the failover. If you initiated a complete failover and it fails, you might need to retry the failover as an immediate failover.

5.4.2.2 How the Broker Performs an Immediate Failover Operation

Once you start an immediate failover, the broker:

1. Verifies that the target standby database is enabled. If the standby database is not enabled for management by the broker, then the failover cannot occur.

2. Stops Redo Apply or SQL Apply on the standby database immediately, without waiting until all available redo data has been applied. This may result in data loss.

3. Transitions the target standby database into the primary role, opens the new primary database in read/write mode, and starts redo transport services.
After an immediate failover completes to a physical standby database, all the standby databases in the configuration, regardless of their type, are disabled. They must be reenabled before they can serve as standby database to the new primary database. See Section 5.4.3 for information.

The broker allows the failover to proceed as long as there are no errors for the standby database that you selected to participate in the failover.

5.4.3 Reenabling Disabled Databases After Failover or Switchover

To restore your original disaster-recovery solution after switchover to a logical standby database or after failover to any standby database, you may need to perform additional steps.

Note:
After switchover to a physical standby database, no additional action is required. The standby databases not involved in the switchover continue to operate in the state they were in before the switchover occurred and will automatically begin applying redo data received from the new primary database.

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 using one of the following procedures:

- If a database can be reinstated, the database will show the following status after a complete failover:

ORA-16661: the standby database needs to be reinstated

Reinstate the database using the DGMGRL REINSTATE DATABASE command or the reinstate option in Enterprise Manager, as described in Section 5.4.3.1, "How to Reinstate a Database".

- If a database must be re-created from a copy of the new primary database, it will have 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. The procedures for creating a standby database are documented in Oracle Data Guard Concepts and Administration. See Section 5.4.3.2, "How to Re-create and Reenable a Disabled Database" for more information.

Note:
Any database that was disabled through multiple role changes cannot be reinstated. You must re-create the database manually and then reenable the database in the broker configuration.

Whether you reinstate or re-create a database depends on if you performed a switchover or failover and on the type of standby database that was the target of the operation.

The following table describes how to reenable disabled databases based on the type of role transition that was performed. The status value associated with databases that are disabled after a switchover or failover will also guide you in choosing which procedure to use. These status values can be viewed in the output from the DGMGRL SHOW DATABASE or on the Data Guard Overview page in Enterprise Manager.

Table 5-1 Reenabling Disabled Databases After Failover or Switchover

Role Transition (Switchover or Failover)

Reinstate or Re-create a Failed Primary Database

Reenabling the Standby Databases Not Involved in the Role Transition

Switchover to a physical standby database

No action is required.

No action is required.

Switchover to a logical standby database

No action is required.

All physical standby databases will be disabled and must be re-created from a copy of the new primary database. Logical standby databases will not be disabled.

Complete failover to a physical standby database

The broker disables the failed primary database during the failover operation. You can reinstate the database if Flashback Database was enabled prior to the failover and there are sufficient flashback logs on the failed primary database.

Otherwise, you must re-create the primary database from a copy of the new primary database.

Physical standby databases that were disabled during failover can be reinstated if Flashback Database was enabled prior to failover and there are sufficient flashback logs on the physical standby database. Otherwise, the physical standby databases must be re-created from a copy of the new primary database.

Logical standby databases disabled during failover must be re-created from a copy of the new primary database.

Complete failover to a logical standby database

The broker disables the failed primary database during the failover. You can reinstate the database if Flashback Database was enabled prior to failover and there are sufficient flashback logs on the failed primary database.

Otherwise, re-create the primary database from a copy of the new primary database.

The broker disables all standby databases not involved in the failover. You must re-create the databases from a copy of the new primary database.

Immediate failover to either a physical or logical standby database

The broker disables the failed primary database during failover. You must re-create the database from a copy of the new primary database.

The broker disables all standby databases not involved in the failover. You must re-create the databases from a copy of the new primary database.

The following sections describe how to reinstate or reenable a database.

5.4.3.1 How to Reinstate a Database

You can use the broker's REINSTATE command to reenable the failed primary database after performing a complete failover to either a physical or logical standby database. You can also use the broker's REINSTATE command to reenable any physical standby databases that were not the target of the failover operation but were disabled during a complete failover to a physical standby database.

Databases that can be reinstated will have the following status value:

ORA-16661: the standby database needs to be reinstated

For the REINSTATE command to succeed, Flashback Database must have been enabled on the database prior to the failover and there must be sufficient flashback logs on that database. In addition, the database to be reinstated and the new primary database must have network connectivity.

To reinstate a database:

1. Restart the database to the mounted state

2. Connect to the new primary database

3. Use Enterprise Manager or DGMGRL to reinstate the database

When reinstating a failed primary database, the broker reenables it as a standby database of the same type (physical or logical standby database) as the old standby database. When reinstating physical standby databases that were disabled during a failover, the broker reenables them as physical standby databases to the new primary database.

Reinstatement Using Enterprise Manager

On the Data Guard Overview page, click the Database must be reinstated link. This brings up the General Properties page that provides a Reinstate button. After you click the Reinstate button, Enterprise Manager begins reinstating the database.

When the process is complete, the database will be enabled as a standby database to the new primary database, and Enterprise Manager displays the Data Guard Overview page.

Reinstatement Using DGMGRL

Issue the following command while connected to any database in the broker configuration, except the database that is to be reinstated:

DGMGRL> REINSTATE DATABASE db_unique_name;

The newly reinstated standby database will begin serving as standby database to the new primary database. If the database is not reinstated successfully, then you must reenable it from a copy of the new primary database, as described in Section 5.4.3.2.

5.4.3.2 How to Re-create and Reenable a Disabled Database

If you performed a failover or switchover that requires you to re-create the failed primary database or standby databases that were disabled during the role transition, follow the procedures in Oracle Data Guard Concepts and Administration.

After the database has been re-created, enable broker management of the re-created standby database by using the DGMGRL ENABLE DATABASE command.

5.5 Fast-Start Failover

Fast-start failover allows the broker to automatically fail over to a previously chosen, synchronized standby database in the event of loss of the primary database. Fast-start failover quickly and reliably fails over the target standby database to the primary database role, without requiring you to perform any manual steps to invoke the failover. Fast-start failover can be used only in a broker configuration and can be configured only through DGMGRL or Enterprise Manager.

This section describes how to enable fast-start failover and an observer site that monitors the fast-start failover environment. The observer is a separate OCI client-side component that runs on a different computer from the primary and standby databases and monitors the availability of the primary database. The observer is described in more detail in Section 5.5.6.

Once the observer is enabled, no further user interaction is required. If both the observer and the standby database lose connectivity to the primary database, the observer waits for the amount of time specified by the FastStartFailoverThreshold property before initiating a fast-start failover. Moreover, after the failover completes, the former primary database is automatically reinstated as a standby database in the new broker configuration when a connection to it is reestablished.

Figure 5-1 shows the relationships between the primary database, target standby database, and the observer during fast-start failover:

- Before Fast-Start Failover: Data Guard is operating in a steady state, with the primary database transmitting redo data to the target standby database and the observer monitoring the state of the entire configuration.

- FastStartFailover Ensues: Disaster strikes the primary database and its network connections to both the observer and the target standby database are lost. Upon detecting the break in communication, the observer attempts to reestablish a connection with the primary database for the amount of time defined by the FastStartFailoverThreshold property before initiating a fast-start failover. If the observer is unable to regain a connection to the primary database within the specified time, and the target standby database is ready for fast-start failover, then fast-start failover ensues.

- After Fast-Start Failover: The fast-start failover has completed and the target standby database is running in the primary database role. After the former primary database has been repaired, the observer reestablishes its connection to that database and reinstates it as a new standby database. The new primary database starts transmitting redo data to the new standby database.

Figure 5-1 Relationship of Primary and Standby Databases and the Observer

The following sections describe these topics:

- Prerequisites for Enabling Fast-Start Failover

- Enabling Fast-Start Failover

- Viewing Fast-Start Failover Configuration Statistics and Status

- Disabling Fast-Start Failover

- Performance Considerations for Fast-Start Failover

- Managing the Observer

- Reinstating the Former Primary Database in the Broker Configuration

- Shutting Down Databases In a Fast-Start Failover Environment

5.5.1 Prerequisites for Enabling Fast-Start Failover

The following prerequisites must be met before the broker allows you to enable fast-start failover:

- Ensure the broker configuration is running in maximum availability mode.

See Section 4.6.1 for information about configuring the protection mode, standby redo logs, and the LogXptMode property.

- Enable Flashback Database and set up a flash recovery area on both the primary database and the target standby database.

See Oracle Database Backup and Recovery Advanced User's Guide) and "Setting Up Flash Recovery Areas as Destinations" in Oracle Data Guard Concepts and Administration.

- Install the DGMGRL command-line interface on the observer computer as described in Section 2.1.

- Configure the TNSNAMES.ORA file on the observer system so that the observer is able to connect to the primary database and the pre-selected target standby database.

5.5.2 Enabling Fast-Start Failover

You can enable fast-start failover from any site, including the observer site, while connected to any database in the broker configuration. Enabling fast-start failover does not trigger a failover. Instead, it allows the observer to begin observing the primary and standby databases and initiate a fast-start failover should conditions warrant a failover.

Perform the following steps to enable fast-start failover and start the observer. The steps assume that you are connected as SYS and that a primary and standby database are already set up in a broker configuration.

Step 1   Determine which of the available standby databases is the best target for the failover.

Follow the guidelines described in Section 5.2, "Choosing a Target Standby Database".

Step 2   Specify the target standby database with the FastStartFailoverTarget property.

When configuring fast-start failover, the FastStartFailoverTarget property on the current primary database, you can specify only one standby database:

- If there is only one standby database in the configuration, you can skip this step and continue with Step 3. The broker will automatically set the FastStartFailoverTarget property on the primary and standby databases to point to each other as their respective target during a failover.

- If there is more than one standby database in the configuration, you must explicitly set the FastStartFailoverTarget property on the primary database and target standby database to point to each other for the purpose of defining which standby database will be the target of a fast-start failover. For example:

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget = 'DR_Sales';
DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY FastStartFailoverTarget = 'North_Sales';

In this example, the current primary database, North_Sales, specifies DR_Sales as its failover target, and the target standby database, DR_Sales, specifies the current primary database as its target. When DR_Sales becomes the primary database it must have a standby target to which it can fail over.

Note:
To change the FastStartFailoverTarget property to point to a different standby database, disable fast-start failover, set the FastStartFailoverTarget property, and restart fast-start failover.

See Section 9.2.9, "FastStartFailoverTarget" for more information about this property.

Step 3   Set the FastStartFailoverThreshold property.

Fast-start failover will occur if both the observer and the target standby database lose connection to the primary database for the period of time specified by the FastStartFailoverThreshold property.

Set the FastStartFailoverThreshold property to specify the number of seconds you want the observer and target standby database to wait (after detecting the primary database is unavailable) before initiating a failover. For example:

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;

This is a configuration-level property and the setting of this property holds for the duration that fast-start failover is enabled. The default value for the FastStartFailoverThreshold property is 30 seconds. If you have a RAC primary database, consider specifying a higher value to minimize the possibility of a false failover in the event of an instance failure.

The time interval starts when the observer first loses its connection to the primary database. If the observer is unable to regain a connection to the primary database within the specified time, then the observer begins a fast-start failover provided the standby database is ready to fail over. Although the default value of 30 seconds is typically adequate for detecting outages and failures on most configurations, you can adjust failover sensitivity with this property to decrease the probability of false failovers in a temporarily unstable environment.

See Also:
Section 9.2.10 for reference information about the FastStartFailoverThreshold property

Step 4   Enable fast-start failover.

Use Enterprise Manager Fast-Start Failover wizard or the DGMGRL ENABLE FAST_START FAILOVER command to enable fast-start failover. To enable fast-start failover, both the primary and target standby databases must be running and have connectivity, and satisfy all of the prerequisite conditions listed in Section 5.5.1.

Enable Fast-Start Failover Using Enterprise Manager

To enable fast-start failover in Enterprise Manager, use the Fast-Start Failover wizard. On the Data Guard Overview Page next to the "Fast-Start Failover" status field, click Disabled to invoke the Fast-Start Failover Page. Then, on the Fast-Start Failover Change Mode Page, click Enabled. The broker will start the observer and change the configuration's protection mode to maximum availability, if necessary. Then, on the Fast-Start Failover Configure Page, select the standby database that should be the target of a failover. See Section 5.2, "Choosing a Target Standby Database" for helpful advice.

1. See Also:
Section 6.4, "Scenario 4: Enabling Fast-Start Failover and the Observer" for an example of the fast-start failover wizard

Enable Fast-Start Failover Using DGMGRL
To enable fast-start failover with DGMGRL, issue the ENABLE FAST_START FAILOVER command while connected to any database system in the broker configuration, including on the observer computer. For example:

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

See Also:
"ENABLE FAST_START FAILOVER" in Chapter 8 and Section 7.6, "Scenario 5: Enabling Fast-Start Failover and the Observer" for examples

If there is only one standby database in the broker configuration, the broker will automatically set the FastStartFailoverTarget property for both the primary and standby databases when fast-start failover is enabled.

Note:
Administration at the target standby site should be as comprehensive as that at the primary site because the standby database may assume the primary role without prior notice. Staff support, hardware and software, security (both software and site), network connections, and bandwidth should be equivalent at both sites.

Step 5   Start the Observer.

To start the observer, only the primary database must be running; it is not necessary for the target standby database to be running.

You can start the observer before or after you enable fast-start failover. However, it is recommended that you have the observer running whenever you have fast-start failover enabled. If fast-start failover is enabled, the observer immediately begins monitoring the status and connections to the primary and target standby databases.

Starting the Observer Using Enterprise Manager

If the Enterprise Manager agent is installed on the observer computer, it automatically starts the observer when you enable fast-start failover through Enterprise Manager. If the agent is not present, you must start the observer manually using the following instructions for the DGMGRL command-line interface.

Starting the Observer Using DGMGRL

To start the observer with DGMGRL, issue the following command on the observer computer:

DGMGRL> START OBSERVER;

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.

See the START OBSERVER command for more information.

Step 6   Verify the fast-start failover environment.

To verify the readiness of the fast-start failover configuration, issue the DGMGRL SHOW CONFIGURATION VERBOSE command on the primary database. For example:

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxAvailability
Fast-Start Failover: ENABLED
Databases:
North_Sales - Primary database
DR_Sales    - Physical standby database
- Fast-Start Failover target
Fast-Start Failover
Threshold: 45 seconds
Observer:  observer.foo.com
Current status for "DRSolution":
SUCCESS

The following sections provide more information about the fast-start failover environment:

- What Happens When Fast-Start Failover and the Observer Are Running?

- Restrictions When Fast-Start Failover is Enabled

- Shutting Down the Primary Database When Fast-Start Failover Is Enabled

- Performing Manual Role Changes When Fast-Start Failover Is Enabled

5.5.2.1 What Happens When Fast-Start Failover and the Observer Are Running?

Once you enable fast-start failover and start the observer, the observer continuously monitors the environment to ensure the primary database is available. This section lists the steps the observer takes to determine if fast-start failover is needed and then performs one, if necessary.

Step 1   Monitor the environment to ensure the primary database is available.

The following list describes some of the conditions with the primary database, system, or site that could cause the observer to attempt a fast-start failover:

- Broken network connection between the observer and the primary database

If the connection is lost between the observer and the primary database, or there are network failures that cause the primary database to be isolated, the observer attempts a fast-start failover.

- Instance failures

If a single-instance primary database (either RAC or nonRAC), or if all instances of a RAC primary database fail, the observer attempts a fast-start failover.

- Shutdown abort

If a single-instance primary database (either RAC or nonRAC), or if all instances of a RAC primary database are shut down with the ABORT option, the observer attempts a fast-start failover. Fast-start failover will not be attempted for the other types of database shutdown (NORMAL, IMMEDIATE, TRANSACTIONAL).

- Offline datafiles

If the observer determines that one or more datafiles in the primary database have been taken offline by the database because of I/O errors, the observer attempts a fast-start failover.

Except for the last condition (Offline datafiles), the observer attempts to reconnect to the primary database within the time specified by the FastStartFailoverThreshold configuration property before attempting a fast-start failover. When the primary database datafiles are offline, the observer initiates a fast-start failover immediately, without waiting for the amount of time specified by the FastStartFailoverThreshold property to expire.

Step 2   Reconnect within the time specified by FastStartFailoverThreshold.

If the observer detects a problem, the observer attempts to reconnect to the primary database within the time specified by the FastStartFailoverThreshold property. The FastStartFailoverThreshold time interval starts when the observer first detects there might be a failure with the primary database.

If the primary database is a Real Application Clusters (RAC) database, the observer will attempt to connect to the remaining primary instances. Fast-start failover will not occur unless all instances comprising the RAC primary database are perceived to have failed.

Note:
If the observer determines that the data files on the primary database are offline but the primary system is running, fast-start failover is initiated immediately without waiting for the FastStartFailoverThreshold interval to expire.

Step 3   Verify the target standby database is ready for failover.

If the primary database is still unavailable when the FastStartFailoverThreshold expires, the observer verifies the target standby database is ready to fail over to the primary database role.

Fast-start failover cannot occur if:

- Fast-start failover is no longer enabled

- The observer cannot connect to the target standby database

See Also:
Section 5.5.6.3, "What Happens if the Observer Fails?" if the observer is not running

- The observer and the target standby database are inconsistent with regard to the current state of the broker configuration

- The observer was stopped, and when it restarted, only the standby database was available

- The target standby database was not synchronized with the primary database at the time the primary database failed

- The target standby database, if it is a logical standby database, is still loading its copy of the former primary database's dictionary (in this case the FS_FAILOVER_STATUS column in the V$DATABASE view contains LOADING DICTIONARY instead of READY)

- The network connection exists between the target standby database and the primary database

- The FS_FAILOVER_STATUS column in the V$DATABASE view for the target standby database displays a reason why fast-start failover cannot occur

- A manual failover is already in progress. See Section 5.4 for complete information about manual failovers.

- The primary database was shut down intentionally, in a controlled fashion

Step 4   Initiate a fast-start failover.

If the target standby database is ready for failover, the observer immediately invokes a fast-start failover. The observer will fail over the target standby database to the primary database role. If failover is not possible for some reason, the observer will try again to connect to the primary database indefinitely.

Step 5   Reinstate the former primary database as a new standby database.

After the fast-start failover completes successfully, the observer will attempt to reinstate the former primary database as a new standby database when a connection to the former primary database is reestablished.

See Also:
Section 5.5.7 for more information about reinstatement

5.5.2.2 Restrictions When Fast-Start Failover is Enabled

When fast-start failover is enabled, you cannot:

- Change:

- The configuration protection mode to either maximum protection or maximum performance

- The LogXptMode property on the primary or target standby databases

- The FastStartFailoverTarget property on the primary or target standby databases

- Disable or delete:

- The broker configuration

- The standby database that is the target of fast-start failover

- Perform a manual failover:

- Unless the conditions listed in Section 5.5.2.4 have been met

- To a standby database that is not configured as the fast-start failover target

- To a standby database that is not synchronized with the primary database, even if it is configured as the target standby database

To determine if the configuration is ready for fast-start failover to occur, issue the DGMGRL SHOW CONFIGURATION command (as shown in Section 5.5.3), or query the V$DATABASE view on either the primary and target standby databases. Fast-start failover is possible if the FS_FAILOVER_STATUS column displays SYNCHRONIZED value and the FS_FAILOVER_OBSERVER_PRESENT column displays YES for the target standby database.

- Perform a switchover to the target standby database unless the standby database is synchronized with the primary database and the observer is running

- Attempt to open the primary database from another Oracle client (for example, with the SQL*Plus SQL> STARTUP command). Doing so will result in the following error begin returned:

ORA-16649: database will open after Data Guard broker has evaluated Fast-Start Failover status

This error occurs because, when fast-start failover is enabled, the broker must perform additional validity checks before allowing the database to open and allowing transactions to commit.

5.5.2.3 Shutting Down the Primary Database When Fast-Start Failover Is Enabled

Fast-start failover will not be triggered if the primary or standby database is shut down normally (using SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL). A normal shutdown will prevent fast-start failover until the primary database and standby database are connected and communicating again.

5.5.2.4 Performing Manual Role Changes When Fast-Start Failover Is Enabled

If fast-start failover is enabled you can still perform a switchover or a manual failover as long as the following conditions are met:

- The role change is directed to the same standby database that was specified with the FastStartFailoverTarget property

- The target standby database is synchronized with the primary database

- For manual failover, the observer is started and communicating with the target standby database

See Also:
Section 5.3 and Section 5.4 for more information about switchovers and manual failovers, respectively

5.5.3 Viewing Fast-Start Failover Configuration Statistics and Status

You can query the V$DATABASE view to verify the observer is started and the configuration is ready for fast-start failover. For example, to verify the observer is started and the configuration is ready for fast-start failover, query the V$DATABASE view on the target standby database or issue the SHOW CONFIGURATION VERBOSE command.

The following example shows the fast-start failover information for the DRSolution configuration:

DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration
Name:                DRSolution
Enabled:             YES Protection Mode:     MaxAvailability
Fast-Start Failover: ENABLED
Databases:
North_Sales - Primary database
DR_Sales    - Physical standby database
- Fast-Start Failover target
Fast-Start Failover
Threshold: 45 seconds
Observer:  observer.foo.com

Current status for "DRSolution":
SUCCESS

When querying the V$DATABASE view, pay special attention to the FS_FAILOVER_STATUS column that can contain the values described in Table 5-2:

Table 5-2 FS_FAILOVER_STATUS Column of the V$DATABASE View

Column Value

Description

Fast-Start Failover ...

DISABLED

Fast-start failover is disabled.

Is not possible

BYSTANDER

Fast-start failover is enabled, but this standby database is not the target of the fast-start failover. The database cannot provide fast-start failover status information.

Is enabled

SYNCHRONIZED

The primary and target standby databases are synchronized.

Is possible if the target standby database displays SYNCHRONIZED and the FS_FAILOVER_OBSERVER_PRESENT column displays YES

UNSYNCHRONIZED

The target standby database does not have all of the primary database redo data.

Is not possible

LOADING DICTIONARY

Displays only on a logical standby database that has not yet completed loading a copy of the primary database's data dictionary.

Is not possible

SUSPENDED

Displays only on the target standby database when either the primary or target standby database was shut down in a controlled fashion (using the NORMAL, IMMEDIATE, or TRANSACTIONAL, options, but not the ABORT option). Fast-start failover is inhibited in the SUSPENDED state. It is cleared upon reconnection to the primary database.

Is not possible

STALLED

Displays on the primary database after loss of connectivity to the target standby database and the change to the UNSYNCHRONIZED state cannot be confirmed by either the target standby database or the observer.

It stalls because it is likely a failover has occurred. Note: this state also occurs during startup when fast-start failover is synchronized and neither the target standby database nor the observer are present to confirm it is okay to continue opening the database.

The primary database will not stall upon loss of connectivity to the target standby database if both the primary and standby databases lost connectivity to the observer more than a minute in the past. Fast-start failover is not possible in this case to allow the primary database to continue committing redo even though neither the target standby database nor the observer are present.

Is possible

PRIMARY UNOBSERVED

Displays only on the target standby database when it is SYNCHRONIZED with the primary database, has connectivity to the observer, but the primary database does not have a connection to the observer. This is a rare state.

Is not possible

REINSTATE REQUIRED

The failed primary database requires reinstatement as a new standby database to the new primary. The observer automatically starts the reinstatement process. REINSTATE REQUIRED is present only after fast-start failover has occurred and shows only on the new primary database.

Has completed

REINSTATE IN PROGRESS

Reinstatement of the failed primary database as a new standby database is in progress.

Has completed

REINSTATE FAILED

Reinstatement of the failed primary database as a new standby database failed. See Section 10.1 for details about the broker's drc* log files.

Has completed

5.5.4 Disabling Fast-Start Failover

Disabling fast-start failover prevents the observer from initiating a failover to the target standby database. In this case, manual failover may still be possible. See Section 5.4 for information about manual failover.

Note:
Disabling fast-start failover does not stop the observer. To stop the observer, see Section 5.5.6.4, "Stopping the Observer".

To disable fast-start failover, use the Fast-Start Failover wizard in Enterprise Manager or the DGMGRL DISABLE FAST_START FAILOVER [FORCE] command. The FORCE option disables fast-start failover on the database to which you are connected even when errors occur. Whether or not you use the FORCE option depends on if the primary and target standby database have network connectivity:

- If the primary and target standby database have network connectivity, Oracle recommends that you use DISABLE FAST_START FAILOVER without the FORCE option. This method will disable fast-start failover on all databases in the broker configuration.

If errors occur during the disable operation, the broker returns an error message and stops the disable operation.

- If the primary and target standby databases do not have network connectivity or if the database to which you are connected does not have network connectivity with the primary database, consider using DISABLE FAST_START FAILOVER with the FORCE option.

The broker may not be able to disable fast-start failover on all databases in the broker configuration when you issue the DISABLE FAST_START FAILOVER FORCE command. As a result, there is no guarantee that the observer will not perform a fast-start failover to the target standby database if the observer determines that conditions warrant a failover. The following list indicates the extent to which fast-start failover is disabled in the broker configuration when the DISABLE FAST_START FAILOVER FORCE command is issued on the primary database, target standby database, and a standby database that is not the fast-start failover target.

If you issue this command on:

- The primary database, the primary database attempts to disable fast-start failover on as many databases in the configuration with which it has a network connection. If the primary database does not have connectivity with the target standby database, fast-start failover remains enabled on the target standby database and the observer may still attempt a fast-start failover if conditions warrant a failover.

Caution:
This action may result in two databases in the configuration simultaneously assuming the primary database role should fast-start failover occur.

- The target standby database when it does not have connectivity with the primary database, fast-start failover is disabled only on the target standby database. In this case, the observer cannot perform a fast-start failover even if conditions warrant a failover. Disabling fast-start failover with the FORCE option when connected to the target standby database is the only method that guarantees fast-start failover will not occur.

If the primary database and the target standby database regain network connectivity, the broker will disable fast-start failover for the entire broker configuration.

- Another standby database that does not have connectivity with the primary database, fast-start failover is disabled for this database. Because fast-start failover was not disabled on the target standby database, the observer may still attempt a fast-start failover to the target standby database should conditions warrant a failover.

Caution:
When you are experiencing network disconnections and you issue the DISABLE FAST_START FAILOVER FORCE command on the primary database or a standby database that does not have connectivity with the primary database, fast-start failover may not be disabled for all databases in the broker configuration. As a result the observer may still initiate fast-start failover to the target standby database, if conditions warrant a failover. This may result in two databases in the configuration simultaneously assuming the primary database role.

Conditions Requiring the FORCE Option

Disabling fast-start failover without the FORCE option can succeed only if the database on which the command is issued has a network connection with the primary database and if the primary database and target standby database have a network connection. This is the recommended method for disabling fast-start failover.

However, there may be situations in which you must disable fast-start failover when the primary database and the target standby database do not have a network connection, or the database on which you issued the disable fast-start failover command does not have a network connection to the primary database. In cases where there is a lost network connection, be aware that the observer may attempt a fast-start failover to the target standby database if conditions warrant a failover.The FORCE option may be the preferred method for disabling fast-start failover when:

- A network outage isolates the primary database from the observer and the target standby database, while the databases are synchronized.

In this case, the primary database stalls and prevents any further transactions from committing because a fast-start failover may have occurred while it was isolated. If you expect the network to be disconnected for a long time, disable fast-start failover with the FORCE option on the primary database to allow processing to continue (without waiting for the connection to the target standby database or the observer computer to be restored).If possible, confirm that fast-start failover has not occurred to the target standby database prior to disabling fast-start failover with the FORCE option on the primary database.

Caution:
This action may result in two databases in the configuration simultaneously assuming the primary database role.

- You want to conduct a manual failover to any standby database in the configuration (for example, because a failure occurred on the primary database at a time when the primary and target standby database were not synchronized).

In this case fast-start failover cannot occur because the databases are not synchronized. You cannot perform a manual failover to the target standby database for the same reason. To proceed, you must first disable fast-start failover using the FORCE option, and then perform a manual failover.

Caution:
This action will result in loss of data and the possibility of two databases in the configuration simultaneously assuming the primary database role.

- A fast-start failover to the target standby database fails.

If the failover fails for any reason, it could leave the target standby database inoperable, regardless of whether the target standby database is synchronized. If there is another standby database that is available for failover, you can perform a manual failover to that standby database after you first disable fast-start failover using the FORCE option on that standby database.

- You want to prevent fast-start failover from occurring because the primary database will resume service soon.

In this case, disable fast-start failover using the FORCE option on the target standby database. Once the primary database regains connectivity with the target standby database, fast-start failover will be disabled for all the databases in the configuration.

Disabling Fast-Start Failover Using Enterprise Manager

Click Disable in the Fast-Start Failover wizard. Then, click Continue to proceed to the next page. See the Enterprise Manager online Help system for more information.

Disabling Fast-Start Failover Using DGMGRL

Issue the DISABLE FAST_START FAILOVER command or the DISABLE FAST_START FAILOVER FORCE command. See the "DISABLE FAST_START FAILOVER" command in Chapter 8 for more information.

Note:
Setting the DG_BROKER_START initialization parameter to FALSE implicitly disables fast-start failover.

5.5.5 Performance Considerations for Fast-Start Failover

Consider the following recommendations to obtain better performance when using fast-start failover:

- Fast-start failover can be faster when the target of the failover is a logical standby database.

This is because a logical standby database does not need to be restarted nor opened (it is already open) to assume the primary role. A physical standby database always needs to be opened, and may need to be restarted if it has been opened read-only since the last time it restarted.

- The failover time is dependent upon whether the target standby database (physical or logical standby database) has applied all of the redo data it has received from the primary database.

- Fast-start failover is faster when you take steps to optimize recovery so that the application of redo data to the standby database is kept up to date with the primary database's rate of redo application. To optimize the log apply rate:

- Do not configure the DelayMins property to delay applying archived redo log files to the standby database (see Section 4.5 for more information)

- See "Tuning the Log Apply Rate for a Physical Standby Database" in Oracle Data Guard Concepts and Administration

- See the Oracle Maximum Availability Architecture white papers at:

http://otn.oracle.com/deploy/availability/

5.5.6 Managing the Observer

The observer is integrated in the DGMGRL client-side component and runs on a different computer from the primary or standby databases and from the computer where you manage the broker configuration. The observer continuously monitors the fast-start failover environment to ensure the primary database is available (described in Section 5.5.2.1). The observer's main purpose is to enhance high availability and lights out computing by reducing the human intervention required by the manual failover process that can add minutes or hours to downtime.

You can manage the observer through either the Data Guard Overview pages in Oracle Enterprise Manager or using DGMGRL commands. Figure 5-2 shows how the observer monitoring a fast-start failover configuration.

Figure 5-2 The Observer in the Fast-Start Failover Environment

The following sections provide information about managing the observer:

- Installing and Starting the Observer

- Viewing Information About the Observer

- What Happens if the Observer Fails?

- Stopping the Observer

- Moving the Observer to Another Computer

- How the Observer Maintains Fast-Start Failover Configuration Information

5.5.6.1 Installing and Starting the Observer

The observer should be installed and run on a computer system that is separate from the primary and standby systems. Installing and starting the observer is an integral part of enabling fast-start failover and is described in detail in these sections:

- Section 2.1 describes installing Oracle Database Enterprise Edition or Oracle Personal Edition on the observer system.

- Section 5.5.2 describes how to start the observer as a part of the step-by-step process to enable fast-start failover. Examples for starting the observer through Oracle Enterprise Manager and DGMGRL are included in Section 6.4 and Section 7.6, respectively.

There can be only one observer monitoring the broker configuration. If you attempt to start another one, the broker returns the following error message:

ORA-16647: could not start more than one observer

To start the observer, you must be able to login to DGMGRL as SYS. The observer is an OCI client that connects to the primary and target standby databases using the same SYS credentials you used when you connected to the Data Guard configuration with DGMGRL.

5.5.6.2 Viewing Information About the Observer

You can find information about the observer by querying the following columns in the V$DATABASE view:

- FS_FAILOVER_OBSERVER_HOST shows the name of the computer on which the observer is running

- FS_FAILOVER_OBSERVER_PRESENT shows whether or not the observer is connected to the local database

Table 5-3 FS_FAILOVER_OBSERVER_PRESENT Column of the V$DATABASE View

Column ValueFoot 1

Description

YES

Observer is currently connected to the local database

NO

Observer is not connected to the local database

Footnote 1 This value is consistent across instances in a Real Applications Cluster (RAC). That is, if the observer is connected to any instance in the RAC, all instances will show a value of YES.

For example, to determine if fast-start failover can occur, the FS_FAILOVER_STATUS column displays SYNCHRONIZED and the FS_FAILOVER_OBSERVER_PRESENT column displays YES for the target standby database. For example:

Database

FS_FAILOVER_STATUS

FS_FAILOVER_OBSERVER_PRESENT

Primary

SYNCHRONIZED

YES

Standby

SYNCHRONIZED

YES

In the following example, assume the network between the primary database and the observer has failed. In this case, the FS_FAILOVER_STATUS and FS_FAILOVER_OBSERVER_PRESENT columns will appear as shown in the following table and fast-start failover will not occur:

Database

FS_FAILOVER_STATUS

FS_FAILOVER_OBSERVER_PRESENT

Primary

SYNCHRONIZED

NO

Standby

PRIMARY UNOBSERVED

YES

5.5.6.3 What Happens if the Observer Fails?

If the primary and target standby databases stay connected but the connection to the observer is lost, then the broker reports that the configuration is not observed. The configuration and database status report that the observer is not running and return the following status messages:

ORA_16658: unobserved Fast-Start Failover configuration
ORA-16820: Fast-Start Failover observer is no longer observing this database

While the configuration is in the unobserved state, fast-start failover cannot happen. Therefore, the primary database can continue processing transactions, even if the target standby database fails. The configuration status returns the SUCCESS status after the observer reestablishes its connection to the primary database, which then notifies the target standby database.

See Also:
Section 5.5.3, "Viewing Fast-Start Failover Configuration Statistics and Status"

5.5.6.4 Stopping the Observer

You may want to stop the observer when you no longer want to use fast-start failover (see Section 5.5.4, "Disabling Fast-Start Failover") or if you want to move the observer to a different host machine (see Section 5.5.6.5, "Moving the Observer to Another Computer").

To stop the observer when fast-start failover is enabled, the primary database and target standby database must be connected and communicating with each other. Stopping the observer does not disable the fast-start failover. However, fast-start failover cannot occur when the primary database is in the unobserved state.

To stop the observer when fast-start failover is not enabled, only the primary database must be running.You can stop the observer while connected to any database in the broker configuration, as follows:

- Using Enterprise Manager

Choose the Stop Observer option on the first page of the fast-start failover wizard and click Continue at the bottom of the page. See the Enterprise Manager online help system for more information.

- Using DGMGRL

Issue the following command:

DGMGRL> STOP OBSERVER;

See the STOP OBSERVER command for more information.

Note:
The observer does not stop immediately when you issue STOP OBSERVER command. When the broker receives the STOP OBSERVER request, it informs the observer the next time the observer contacts the broker.

5.5.6.5 Moving the Observer to Another Computer

To move the observer to another computer:

1. Stop the observer from any computer system in the broker configuration, as described in Section 5.5.6.4.

2. Start the observer on the new computer system, as described in Step 5 of Section 5.5.2.

There is no need to disable fast-start failover when you move the observer.

5.5.6.6 How the Observer Maintains Fast-Start Failover Configuration Information

The observer persistently maintains information about the fast-start failover configuration in a binary file created in the working directory where you started the observer. By default, the observer creates this file when it is started and names the file fsfo.dat. This file contains connect descriptors to both the primary and the target standby databases. Ensure this file cannot be read by unauthorized users.

Once the file is created, you cannot change its name and location. However, you can change the name or the location of the file if you use the DGMGRL START OBSERVER command and include the FILE qualifier. See the START OBSERVER command for more information.

Note:
If the observer is stopped abnormally (for example, by typing CTRL/C), restart it and reference the existing fsfo.dat file with the FILE qualifier.

5.5.7 Reinstating the Former Primary Database in the Broker Configuration

After a fast-start failover completes successfully, the observer automatically attempts to reinstate the former primary database as a standby database. Reinstatement restores high availability to the broker configuration so that, in the event of a failure of the new primary database, another fast-start failover can occur. The reinstated database can act as the fast-start failover target for the new primary database, making a subsequent fast-start failover possible. The new standby database is a viable target of a failover when it begins applying redo data received from the new primary database.

The broker can reinstate the former primary database as a standby database without the need to reenable the primary database or manually performing the Flashback Database operation. To reinstate the former primary database, the database must be started and mounted, but it cannot be opened. The broker reinstates the database as a standby database of the same type as the former standby database.

If the former primary database cannot be reinstated automatically, you can manually reinstate it using either the DGMGRL REINSTATE command or Enterprise Manager. Step-by-step instructions for manual reinstatement are described in Section 5.4.3.

5.5.7.1 Requirements

Reinstatement is supported only after failover in a broker configuration. It also requires Flashback Database to be enabled on both the primary and target standby databases. Section 5.5.1 provides complete information about all of the fast-start failover and reinstatement requirements.

5.5.7.2 Restrictions on Reinstatement

The broker cannot automatically reinstate the former primary database if:

- Another failover or switchover occurred after the fast-start failover completed but before the former primary database restarted.

- Fast-start failover was disabled.

- The observer cannot connect to the former primary database.

- The former primary database cannot connect to the new primary database.

- The former primary database and the new primary database are not configured in the same fast-start failover environment.

- The former primary database was disabled because of a manual failover, not a fast-start failover.

Note:
Standby databases that are disabled during switchover, manual failover, or fast-start failover cannot be automatically reinstated.

If automatic reinstatement fails, the broker will log errors and the former primary database will remain in the mounted state. At this point, you can either:

- Disable fast-start failover (described in Section 5.5.4) and attempt to open the former primary database.

- Manually reinstate the former primary database, as described in Section 5.4.3.

5.5.7.3 How the Broker Handles a Failed Reinstatement

If a failure occurs once a reinstatement operation (automatic or manual) is underway, the broker logs the appropriate information in the broker configuration files and log files. The former primary database is disabled. Most in-progress failures cannot be restarted (for example, archived redo log file corruption on the primary database). You must reenable the database as a standby database manually, as described in Oracle Data Guard Concepts and Administration.

5.5.8 Shutting Down Databases In a Fast-Start Failover Environment

Perform the following steps if you need to shut down the primary or standby databases:

1. Shut down the observer and wait for the FS_FAILOVER_OBSERVER_PRESENT column in the V$DATABASE fixed view to contain the value "NO" for both the primary and target standby databases.

2. Shut down the primary database and the target standby database using either DGMGRL SHUTDOWN command or the SQL*Plus SHUTDOWN statement.

When restarting the databases, you may restart them in any order. When both databases have been restarted, you may restart the observer.

6 Scenarios Using Oracle Enterprise Manager

This chapter provides several scenarios that show how to use the Oracle Enterprise Manager graphical user interface (GUI)Foot 1  to create, manage, and monitor a Data Guard configuration.

This chapter contains the following scenarios:

- Scenario 1: Accessing the Data Guard User Interface

- Scenario 2: Creating a Configuration or Adding an Additional Standby Database

- Scenario 3: Adding an Existing RAC Standby Database

- Scenario 4: Enabling Fast-Start Failover and the Observer

- Scenario 5: Performing Routine Maintenance

- Scenario 6: Performing a Switchover Operation

- Scenario 7: Invoking a Failover Manually

- Scenario 8: Monitoring a Data Guard Configuration

- Scenario 9: Using Metrics

- Scenario 10: Removing a Standby Database and Configuration

6.1 Scenario 1: Accessing the Data Guard User Interface

Access the Data Guard Web pages through the Oracle Enterprise Manager Grid Control using the following steps:

Note:
Oracle Enterprise Manager Grid Control provides access to the complete set of Data Guard features. Limited monitoring-only Data Guard functionality is available in Enterprise Manager Database Control.

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 see a listing of all discovered databases. In this scenario, the primary database, North_Sales, has already been discovered. Click the North_Sales database to go to the primary database home page.

4. Click Maintenance.

5. In the High Availability section under Data Guard, click Setup and Manage and log in.

Note:
If you log in as a user with SYSDBA privileges, you will have access to all Data Guard functionality, including all monitoring and management features. If you log in as a non-SYSDBA user, you will have access to monitoring functions only; features such as standby creation, switchover, and failover will not be available.

If the primary database is not already in a broker configuration, clicking Setup and Manage in Step 5 will go to the page shown in Figure 6-1. This screenshot shows information presented on the All Targets tab, containing graphs for all targets discovered for the cluster. From the list of managed targets, you can quickly assess the availability of the targets and click any graph to drill down for more information.

See Also:
Section 6.2, "Scenario 2: Creating a Configuration or Adding an Additional Standby Database"

Figure 6-1 Create a Broker Configuration

If the primary database is already part of a broker configuration, clicking Setup and Manage in Step 5 will go to the Data Guard Overview page as shown in Figure 6-2.

Figure 6-2 Data Guard Overview Page

On the Data Guard Overview page, you can:

- Edit the protection mode—click Protection Mode in the Data Guard Overview section to view the current protection mode setting and, if necessary, change the protection mode.

- Enable Fast-Start Failover—click Disabled to invoke the Fast-Start Failover wizard that will guide you through the process of enabling fast-start failover and the observer.

- View a summary of standby progress—this chart shows the amount of data that each standby database has not yet received and applied.

- Retrieve information about the primary database—click Name, Host, Status, Current Log, or Properties (Edit) to view pertinent information about the primary database.

If you click Status or Edit, you are taken to the Edit Properties page where you can view and change the current state or properties of the primary database.

- View or change information on the standby databases:

- Add a standby database to the broker configuration—click Add Standby Database to add a physical or logical standby database.

- Change the state or properties—click Edit to go to the Edit Properties page to view and change the current state or properties of the standby database.

- Discontinue Data Guard broker control—click Remove to remove the selected standby database from Data Guard broker control.

- Switch the role from standby to primary—click Switchover to switch the database roles from standby to primary.

- Transition the standby database to the role of primary database— click Failover when a catastrophic failure occurs on the primary database, and there is no possibility of recovering the primary database in a timely manner. The target standby database assumes the primary role, and the failed primary database is disabled by the broker. See Section 5.4.3 for steps to reenable the failed primary database as a standby database to the new primary database.

- View performance information for the configuration and status of online redo log files for each standby database:

- Click Performance Overview to view information about data archived and applied, a summary of standby progress, and a summary of log services.

- Click Log File Details to view the status of online redo log files that were generated on the primary database but not received by the standby, and for online redo log files that were received but not applied to the standby database

- Perform additional administrative activities:

- Click Verify to check the protection mode and properties, confirm that standby redo log files are present, and verify log switch.

- Click Remove Data Guard Configuration to remove the broker configuration from Data Guard broker control.

- Search for information about any Enterprise Manager topic—Click Help to display the Welcome to Oracle Data Guard help topic. Once in the online Help system, you can use the Contents page or Search page to locate help topics of interest.

6.2 Scenario 2: Creating a Configuration or Adding an Additional Standby Database

Creating a broker configuration is the first thing you must do before you can manage and monitor the databases. Enterprise Manager provides the Add Standby Database wizard to create a broker configuration that includes a primary database and one or more standby databases. This scenarios shows how to use the Add Standby Database wizard later to add a logical standby database to a broker configuration that already has one physical standby database (DR_Sales). To start the Add Standby Database wizard, click Add Standby Database on the Data Guard Overview page.

After clicking Add Standby Database, you can select one of the following options:

- Create a new physical standby database (single-instance only)

- Create a new logical standby database (single-instance only)

- Manage an existing standby database with Data Guard broker..

- Create a primary database backup only

You will need to connect to the primary database using SYSDBA credentials, if you are not yet connected.

See Also:
Oracle Data Guard Concepts and Administration for the steps about how to create a RAC standby database

Figure 6-3 show the introductory page of the create configuration process.

Figure 6-3 Add Standby Database Wizard - Introductory Page

The Add Standby Database wizard takes you through the following steps:

1. Determine the backup type.

2. Set up the backup options.

3. Select the Oracle home in which to create the standby database.

4. Set up the location for standby database files.

5. Provide standby database configuration parameters.

6. Review the information before clicking Finish.

The following steps assume a broker configuration already exist with one primary database and one physical standby database, and creates a new logical standby database. It shows how the wizard takes you through additional steps to select the Oracle home for the database and to copy datafiles to the standby database.

Step 1   Determine the backup type.

Enterprise Manager uses Oracle Recovery Manager (RMAN) to create a single-instance standby database from a new or existing backup of the primary database. You can select one of two backup operations to use for the standby database creation:

- Perform a live backup of the primary database

- Use an existing backup of the primary database

Figure 6-4 shows Step 1 of 6 of the configuration process if you are adding a logical standby database.

Figure 6-4 Add Standby Database Wizard - Backup Type (Logical Standby Database)

You can click Cancel to terminate the current process and begin again at the introductory page of the Add Standby Database wizard.

Figure 6-5 shows additional screen content that appears when you are adding a logical standby database.

Figure 6-5 Add Standby Database Wizard - Backup Type (Logical Standby Database)

Step 2   Set up the backup options.

A working directory is needed to store the primary database backup files. It can optionally be retained and used to create additional standby databases in the future. Specify a location on the primary host in which the working directory can be created.

Primary host credentials are required for this step. Enter the credentials of the owner of the primary database Oracle server installation. These credentials can be saved by checking the box marked Save as Preferred Credential.

You can click Cancel to terminate the current process and begin again at the introductory page of the Add Standby Database wizard.

Figure 6-6 shows Step 2 of 6 of the configuration process.

Figure 6-6 Add Standby Database Wizard - Backup Options

Step 3   Select the Oracle home in which to create the standby database.

The standby database can be created in any Oracle home that was discovered by Oracle Enterprise Manager. Only Oracle homes on hosts that match the operating system of the primary host are shown. You must select a discovered Oracle home and provide a unique instance name for the standby database. Standby host credentials are required to continue.

Figure 6-7 shows Step 3 of 6 of the configuration process.

Figure 6-7 Add Standby Database Wizard - Database Location

Step 4   Set up the location for standby database files.

Part of the create broker configuration process involves making the datafiles for the primary database available to the standby host. You have the option of customizing the location for the standby database files. Standby host credentials are required to continue. The following list describes your options:

- Specify the backup file access method

Choose the method by which you want to make the primary database backup files accessible to the standby host. The two options are:

- Transfer files from the primary host working directory to a standby host working directory

- Directly access the primary host working directory location from the standby host using a network path name

- Specify the standby database file location

Choose the locations for the standby database files. You have two options:

- Convert to Oracle OFA (Optimal Flexible Architecture)

- Keep file names and locations the same as the primary database

- Specify the network configuration file location

Data Guard will add configuration information for the standby database to the network configuration files (listener.ora and tnsnames.ora) in the specified directory on the standby host.

You can click Cancel to terminate the current process and begin again at the introductory page of the Add Standby Database wizard.

Figure 6-8 shows Step 4 of the configuration process.

Figure 6-8 Add Standby Database Wizard - File Locations

Step 5   Provide standby database configuration parameters.

Standby database configuration parameters must be set. These parameters include the database name, database unique name, target name, and standby archive location. The standby archive location can be a regular directory or a flash recovery area. The default values are based on corresponding primary database settings.

You can click Cancel to terminate the current process and begin again at the introductory page of the Add Standby Database wizard.

Figure 6-9 shows Step 5 of 6 of the configuration process.

Figure 6-9 Add Standby Database Wizard - Configuration

Step 6   Review the information before clicking Finish.

The Add Standby Database wizard allows one last review of the data you input for the configuration and standby database. Click Finish when you are certain all of the information is correct.

You can click Cancel to terminate the current process and begin again at the introductory page of the Add Standby Database wizard.

Figure 6-10 shows Step 6 of 6 of the configuration process.

Figure 6-10 Add Standby Database Wizard - Review

By clicking Standby Database Storage, you can see additional information about all the standby database file locations.

Once you click Finish, the standby database creation process runs as an Oracle Enterprise Manager job. You can cancel the standby creation at any point before the job submission. Figure 6-11 shows the standby database creation process.

Figure 6-11 Add Standby Database Wizard - Processing

After the job is submitted, you will be returned to the Data Guard Overview page. In the Status column of the Standby Databases table, you will see Creation in progress listed. If you click that link, you can monitor the progress of the standby database creation. Figure 6-12 shows the Data Guard Overview page with this link.

To add additional standby databases after the initial creation of the configuration, click Add Standby Database to run the Add Standby Database wizard again.

Figure 6-12 Data Guard Overview Page - Creation in Progress

6.3 Scenario 3: Adding an Existing RAC Standby Database

Although the Add Standby Database wizard will not create a RAC standby database, you can add an existing RAC standby database into a Data Guard configuration. Click Add Standby Database to run the Add Standby Database wizard and select Add an existing standby database.

Figure 6-13 shows the Add Standby Database introductory page.

Figure 6-13 Adding an Existing RAC Standby Database to the Data Guard Configuration

The Add Standby Database wizard takes you through the following steps:

1. Select an existing standby database.

2. Set the standby archive location setting.

3. Review the configuration settings.

Step 1   Select an existing standby database.

In this step, select the RAC standby database you want to add to the configuration. All discovered databases in your environment (both RAC and non-RAC databases) will be shown in the list. In the example shown in Figure 6-14 (Step 1 of 3), one of the databases in the list (RAC10g) is a RAC standby database.

You can click Cancel at any time to terminate the current process and begin again at the introductory page of the Add Standby Database wizard.

If you wish to continue, click Next.

Figure 6-14 Select an Existing Standby Database

Step 2   Set the standby archive location setting.

You can optionally change the Standby Archive Location setting of the existing standby cluster database, as shown in Figure 6-15 (Step 2 of 3).

If you wish to continue, click Next.

Figure 6-15 Add Standby Database: Standby Configuration

Step 3   Review the configuration settings.

Review the data for the configuration and standby database, as shown in Figure 6-16 (Step 3 of 3).

You can click Cancel to terminate the current process and begin again at the introductory page of the Add Standby Database wizard.

If you wish to complete the operation, click Finish.

Figure 6-16 Add Standby Database: Review

6.4 Scenario 4: Enabling Fast-Start Failover and the Observer

You can enable fast-start failover from any site, including the observer site, while connected to any database in the broker configuration. Enabling fast-start failover does not trigger a failover. Instead, it allows the observer to begin observing the primary and standby databases and initiate a fast-start failover should conditions warrant a failover.

This section describes the steps to enable fast-start failover and the observer:

1. Invoke the Fast-Start Failover wizard.

2. Configure the target database and fast-start failover properties.

3. Enable Flashback Database.

4. Confirm that you want to enable fast-start failover.

Step 1   Invoke the Fast-Start Failover wizard.

On the Data Guard Overview Page next to the "Fast-Start Failover" status field, click Disabled to invoke the Fast-Start Failover wizard.

Step 2   Configure the target database and fast-start failover properties.

On the Fast-Start Failover Configure Page:

- Select the standby database that you choose to be the target of fast-start failover and set fast-start failover properties. The example shown in Figure 6-17 chooses DR_Sales, a physical standby database, to be the target standby database.

See Also:
Section 5.2 for helpful advice on determining which standby database will make the best target for a failover

Figure 6-17 Fast-Start Failover Wizard: Configure

- Click Set Observer to specify the system on which the observer will run and the Oracle home:

- If an observer is not currently defined, the Observer Host and Home fields are blank. You can directly edit the Observer Host and Home fields (in which case the specified host must already be discovered by Enterprise Manager), or you can choose from the list of discovered hosts and their Oracle Homes provided by Enterprise Manager. If you leave the Observer Host and Home fields blank, you may still configure fast-start failover, but you must then manually start an observer for fast-start failover to be ready for fast-start failover.

- If an observer host and home is already known to Enterprise Manager, the Observer Host field displays those values when the Set Observer page is displayed. You can change the observer location, in which case the current observer will be stopped and Enterprise Manager will run a remote operation to start the new observer on the specified host.

Figure 6-18 shows the Set Observer page.

Figure 6-18 Fast-Start Failover Wizard: Set Observer

- Set the FastStartFailoverThreshold property to specify the number of seconds you want the observer and target standby database to wait (after detecting the primary database is unavailable) before initiating a failover

See Also:
Section 9.2.10 for more information about the FastStartFailoverThreshold property

- Click Continue.

Step 3   Enable Flashback Database.

The next page of the Fast-Start Failover wizard enables flashback logging on the primary and standby databases. If either the primary database or the target standby database does not have flashback logging enabled, the page shown in Figure 6-19 will display. On this page you can specify the flash recovery area location, flash recovery area size, and flashback retention time for each database for which flashback logging must be activated.

Figure 6-19 Fast-Start Failover Wizard: Enable Flashback Logging

Step 4   Confirm that you want to enable fast-start failover.

Enterprise Manager displays the Confirmation page shown in Figure 6-20 to verify that you want to start fast-start failover.

Figure 6-20 Fast-Start Failover Wizard: Confirmation

If you click Yes to continue with an enable operation, the Enterprise Manager processing page shown in Figure 6-21 displays. The processing page provides a progress bar and a list of the steps that are being undertaken during the enable operation. The fast-start failover wizard performs the following steps:

1. Creates standby redo log files on the primary and standby databases

2. Upgrades the protection mode to Maximum Availability, if required

3. Restarts the primary and standby databases, if required

4. Enables fast-start failover

5. Starts the observer process

Some steps may not be performed. For example, because fast-start failover requires the Data Guard configuration is running in maximum availability mode, this scenario includes the Changing Protection Mode step to upgrade the configuration's protection mode from maximum performance to maximum availability.

Figure 6-21 Fast-Start Failover Wizard: Progress

When the operation completes, Enterprise Manager displays the Data Guard Overview page that shows an Enabled status along with the Observer Host.

Figure 6-22 shows how, in this scenario, fast-start failover is "Enabled to DR_Sales." If you were to click this status field, the Fast-Start Failover wizard would be invoked again to lead you through the steps to disable fast-start failover.

Figure 6-22 Fast-Start Failover Is Successfully Enabled

Once fast-start failover and the observer are enabled, the observer continuously monitors the environment to ensure the primary database is available. If the observer detects a problem, the observer attempts to reconnect to the primary database within the time specified by the FastStartFailoverThreshold property. If the problem is not remedied in that time and the target standby database is ready for failover, the observer immediately invokes a fast-start failover. Because a fast-start failover is automatic and fast, you may not be aware it has happened until you notice that reinstatement is needed or is already occurring.

Figure 6-23 shows an example of the warning message that shows when a reinstatement is needed.

Figure 6-23 Reinstating the Former Primary Database After a Fast-Start Failover

You can also obtain information about your fast-start failover environment by looking at the metrics in the Alert Log Errors page. This page enables you to view a list of log entries containing errors. To see database alerts, navigate to the Database Home page and choose the Alert Log link from the Diagnostic Summary section. The errors are listed in a table that includes a severity level and time stamp for each row. The Category column provides a description of the category type of the error. You can filter the list using View Data to display a day's, week's, or month's worth of data.

Figure 6-24 shows an example of the Alert Log Errors page for the North_Sales database after a fast-start failover occurred.

Figure 6-24 Alert Log Errors Page Showing That Fast-Start Failover Occurred

See Also:
Section 5.5 for complete information about fast-start failovers, the observer, and reinstating the failed primary database

6.5 Scenario 5: Performing Routine Maintenance

Enterprise Manager simplifies some of the routine maintenance tasks you must perform in the configuration. The following examples, provided in the following sections, show:

- Changing the State of a Database

- Changing the Properties of a Database

- Changing the Database Protection Mode

6.5.1 Changing the State of a Database

This section describes how to set the standby database to Log Apply Off.

To change the state of the standby database to Log Apply Off, follow these steps:

1. From the Data Guard Overview page, select the standby database you want to change to the Log Apply Off state.

2. Click Edit to go to the Edit Properties page.

3. Select Log Apply Off.

4. Click Apply.

5. When the process completes, a message indicating success is returned.

Figure 6-25 shows the Edit Properties page where you can change the state of a database.

Figure 6-25 Changing the State or Properties of a Database

When you change the state of the standby database to Log Apply Off, it stops Redo Apply (or SQL Apply for logical standby databases) from applying the redo data to the standby database. However, redo transport services on the primary database are unaffected; the standby database continues to receive redo data from the primary database.

After completing your maintenance tasks, you can follow the same sequence of steps to bring the database online again.

6.5.2 Changing the Properties of a Database

Enterprise Manager divides the database properties into primary, standby, and common properties.

To view or change properties:

1. Click either Edit from the Primary Database section or click Edit from the Standby Databases section of the Data Guard Overview page.

2. Click one of the following:

- Standby Role Properties

- Common Properties

3. Make the appropriate change and click Apply.

4. When the process completes, a message indicating success is returned.

Figure 6-26 shows properties specific to the standby database.

Figure 6-26 Standby Role Properties

By clicking Show Advanced Properties, you can view additional properties specific to the standby database, as shown in Figure 6-27.

Figure 6-27 Standby Advanced Properties

Figure 6-28 shows properties common to both the primary database and the standby database.

Figure 6-28 Common Properties

6.5.3 Changing the Database Protection Mode

You can change the broker configuration's overall protection mode with Enterprise Manager.

When the configuration was first created it was placed in the maximum performance mode by default. This section describes the process for upgrading to the maximum protection mode. The maximum protection mode guarantees that no data loss will occur if the primary database fails.

To set the maximum protection mode:

1. Click Maximum Performance under the Overview section on the Data Guard Overview page.

2. Select Maximum Protection and click Continue.
Figure 6-29 shows the Edit Protection Mode page.

Figure 6-29 Change Protection Mode Page

3. Select one or more of the standby databases listed in Figure 6-30 that you want to support the maximum protection mode. The redo transport service (and LogXptMode property) will automatically be set to SYNC for the primary database and the selected standby databases.
Data Guard broker 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. Click Continue to go on.

Figure 6-30 Change Protection Mode - Standby Databases and Online Redo Log Files

4. Confirm that you want to change the protection mode. Click Yes to continue or No to cancel. This scenario assumes you are accepting the change by clicking Yes. Then, the Edit Protection Mode Processing page is displayed, as shown in Figure 6-31.

Figure 6-31 Change Protection Mode - Process

5. Once the protection mode is successfully updated, the Data Guard Overview page is displayed as shown in Figure 6-32.

Figure 6-32 Protection Mode Successfully Changed

6.6 Scenario 6: Performing a Switchover Operation

There may be occasions when you might want to perform a switchover between the primary database and standby databases. This scenario steps you through the process of using the switchover operation to switch roles between the primary database and a standby database.

To execute a switchover, perform the following steps:

1. Select the standby database that you want to become the primary database.

2. Click Switchover.

3. Click Yes to continue with the switchover. Click No to cancel.

Figure 6-33 shows the Switchover Confirmation page.

Figure 6-33 Switchover Operation

The Switchover operation performs the following steps:

1. Ensures that the primary database and standby database are not currently in an error status condition and verifies that broker management of the primary database is enabled and online.

2. If the switchover target is a physical standby database, you can view any active user sessions connected to the primary using the Browse Primary Database Sessions link. These sessions will be closed automatically during the switchover.

3. Performs the switchover by first changing the primary database to the standby role, and then the standby database to the primary role, displaying a progress indicator as the switchover progresses.

4. If the switchover target is a physical standby database, both it and the primary database will be restarted.

Figure 6-34 shows the Processing page during the switchover.

Figure 6-34 Processing Page During Switchover

Figure 6-35 shows the Data Guard Overview page after a successful switchover.

Figure 6-35 New Primary Database After Switchover

6.7 Scenario 7: Invoking a Failover Manually

This scenario steps you through the process of using the Failover operation to transition one of the physical standby databases, in this case DR_Sales, into the primary role. You should perform a failover only in the event of a software or system failure that results in the loss of the primary database. The failed primary database is disabled by the broker and must be reenabled, and the standby database assumes the primary database role. See Section 5.4.3 for steps to reenable the failed primary database as a standby database to the new primary database.

In Figure 6-36 the Data Guard Overview page shows the ORA-16625 error status that indicates problems accessing the primary database.

Figure 6-36 Data Guard Overview Page Showing ORA-16625 Error

To transition DR_Sales into the primary role, select DR_Sales in the Standby Databases table and click Failover.

Figure 6-37 shows the Failover Confirmation page.

Figure 6-37 Failover Confirmation Page

If you determine that a failure occurred on the primary database and there is no possibility of recovering the primary database in a timely manner, you can start the Failover operation. In configurations with both physical and logical standby databases, Oracle recommends using the physical standby database as the failover target because it will allow the logical standby database to continue to function as a logical standby to the new primary database. If the failover is made to the logical standby, any physical standbys in the configuration will need to be re-created from a backup of the new primary database.

The Failover operation enables you to choose one of the following two types of failover operations:

- Complete—attempts to minimize data loss by applying all available redo on the standby database.

- Immediate—no additional data will be applied on the standby database; data may be lost. This is the fastest type of failover.

Figure 6-38 shows the progress of the failover operation.

Figure 6-38 Failover Progress Page

During the failover, the selected standby database transitions into the primary role. If the failover target is a physical standby database, it is restarted. When completed, the Data Guard Overview page reflects the updated configuration, as shown in Figure 6-39.

Figure 6-39 Data Guard Overview Page After a Failover Operation Completes

In the figure, the Data Guard Status column indicates that the original primary database (North_Sales) is disabled and can no longer be managed through Enterprise Manager until it has been reenabled as a physical standby database.

See Also:
Section 5.4.3 for more information about post-failover steps to reenable databases

6.8 Scenario 8: Monitoring a Data Guard Configuration

Enterprise Manager provides ways to monitor the status of a configuration as well as the online redo log file activity of the primary and standby databases. At the most basic level, the Data Guard Overview page for the configuration not only displays information about the configuration, but it also includes summary information about its databases.

Note:
You can access the monitoring functions of Data Guard even if you are logged in as a non-SYSDBA user. However, all management features, such as standby creation, switchover, and failover, require a SYSDBA connection.

For example, the summary information on the Data Guard Overview page shows the status for all of the databases in the configuration. If you want more information about why Redo Apply or SQL Apply are off for a specific standby database, select the Status link of the database in the Standby Databases table and view the property pages. Any Data Guard specific database properties that are incorrect, inconsistent, or known to be in conflict with other parameters will be flagged with a warning in the Edit Properties page for the database. A variety of icons indicating the status condition can appear next to the Status link. A green check mark appears if the primary database is functioning normally; a yellow triangle containing an exclamation mark appears if there is a warning; and a red X appears if there is an error condition.

- To check the primary database status, select Status under the Primary Database section of the Data Guard Overview page.

- To check the status of a standby database listed in the Standby Databases table, select the link under the Status column.

For example, a yellow warning icon may display the message "A yellow warning indicates an inconsistent property has been detected. The value for this property is inconsistent between Data Guard and the database, Data Guard and the server parameter file, or Data Guard and both the database and server parameter file."

Figure 6-40 shows the Data Guard Overview page in the case where the configuration has returned an error because the observer is no longer observing the fast-start failover configuration.

Figure 6-40 Data Guard Overview Page Showing Observer Error

The following sections provide information on ways to monitor the status and health of a configuration:

- Section 6.8.1, "Verifying a Broker Configuration"

- Section 6.8.2, "Viewing Log File Details"

- Section 6.8.3, "Monitoring Configuration Performance"

6.8.1 Verifying a Broker Configuration

Another way to quickly check the overall health of a broker configuration is to run the Verify operation. The Verify operation performs a series of validation checks on the broker configuration, including a health check of each database in the configuration. The checks include:

1. Shows the current data protection mode setting, including the current redo transport service settings for each database and whether or not the standby redo log files are configured properly. If standby redo log files are needed for any database, the Verify results will allow you to automatically configure them.

2. Validates each database for the current status.

3. Performs a log switch on the primary database and then verifies that the log file was applied on each standby database.

4. Shows the results of the Verify operation, including errors, if any. The Verify operation completes successfully if there are no errors and an online redo log file was successfully applied to at least one standby database.

5. Shows any databases or RAC instances that are not discovered. Undiscovered databases and instances could prevent a failover or switchover from completing successfully.

6. Detects inconsistencies between database properties and their corresponding values in the database itself. It also provides a mechanism for resolving these inconsistencies.

Note:
You can click Cancel at any time to stop the Verify operation.

To verify the configuration, click Verify under the Additional Administration section of the Data Guard Overview page. See Figure 6-41. The Verify command displays a progress indicator. When the Verify operation completes successfully, the broker configuration is healthy, guarding the data, and ready for a switchover or failover.

Figure 6-41 Verifying the Configuration

When the Verify operation completes successfully, the broker configuration is healthy, guarding the data and ready for a switchover or failover operation. The Verify processing page can be canceled at any time.

Figure 6-42 shows the results after the successful completion of the Verify operation.

Figure 6-42 Results of the Verify Command

6.8.2 Viewing Log File Details

For each standby database in the configuration, there is a table that shows the status of archived redo log files that were generated on the primary database but not received by the standby database, and for archived redo log files that were received but not applied to the standby database. This Log File Details page is useful to determine log file information when redo transport or log apply services are stopped. Under normal operations, each standby table is empty.

For example, if redo transport services go offline unexpectedly, the primary database continues to generate archived redo log files, but redo transport services will not send the archived redo log files to the standby databases. You can view the Log File Details page to find out which log files have not yet been received for each standby database.

On the Log File Details page, there is a Primary Current Log entry that indicates the log sequence number of the current log file on the primary.

For each standby database, redo transport and log apply information is displayed to help diagnose any log file buildup. Table 6-1 describes the columns for the standby table:

Table 6-1 Log File Details Page

Column Title

Description

Log

The log sequence number.

Status

The status of the log file.

Not Received

The log file has not been received.

Not Applied

The log file has not been applied.

First Change # (SCN)

The first system change number.

Last Change # (SCN)

The last system change number.

Size (KB)

The size, in kilobytes, of the log file.

Time Generated

The time when the log file was generated.

Time Completed

The time at which the log file was completed.

Click Log File Details from the Data Guard Overview page to see the page shown in Figure 6-43.

Figure 6-43 Viewing Log File Details

6.8.3 Monitoring Configuration Performance

For more in-depth performance and monitoring, you can display detailed performance statistics for a broker configuration using performance charts that provide a graphical summary of all online redo log file activity in the configuration. The charts are refreshed based on a collection interval (the rate at which data is sampled from the primary database) that you can specify. The default collection interval is 30 seconds, which can be changed. See the online Help for detailed information about performance sampling rates.

The Performance Overview page collects performance related information from all of the databases in the configuration. All charts are represented by metrics. Typically, the charts show two hours worth of data. You can click any chart to view historical data (for example, 24 hours a day, 7 days a week, 31 days a month). Rates are calculated by determining the amount of redo (applied or generated) divided by the collection interval (default is 1 minute for the performance page, 5 minutes for metrics).

- Redo Generation Rate -- This chart shows the redo generation rate (KB/sec) on the primary.

- Lag Times -- Shows the Transport Lag (the approximate number seconds of redo not yet available on the standby database) and Apply Lag (The approximate number of seconds the standby is behind the primary database).

- Apply Rate -- Displays the standby apply rate (KB/sec). The Current Redo Generation Rate shows the last value. The Apply Rate When Active value (last 3 logs, KB/sec) shows the actual apply rate when averaged over the last three log files.

- Test Application -- The test application is a built in application which will generate a workload on the primary database. This is an easy way view the performance metrics when the primary database is under a load.

- Overview -- Shows the primary database name and status. Click the status link to view the historical summary of the status metric. Note: the status on the performance page is shown directly from the status metric which runs at 5 minute collection intervals. The status on the Data Guard Overview Page is always updated on every refresh.

Figure 6-44 Performance Page

The Performance Overview page begins charting information as soon as the page is displayed. Data will not be collected for any offline or disabled databases.

6.9 Scenario 9: Using Metrics

Oracle Enterprise Manager automatically monitors the status and redo log file activity on the primary and standby databases. The following list shows the Data Guard metrics:

- Data Guard Fast-Start Failover:

- Fast-Start Failover Occurred

- Fast-Start Failover SCN

- Fast-Start Failover Time

- Data Guard Performance

- Apply Lag (seconds)

- Estimated Failover Time (seconds)

- Redo Apply Rate (KB/second)

- Transport Lag (seconds)

- Data Guard Status

You can set up Email Services to notify you through your e-mail if any of the metrics are triggered.

See Also:
Enterprise Manager help and documentation for more information about registering metrics and using Email Services

6.9.1 Understanding the Data Guard Metrics

The following sections provide additional information about the Data Guard metrics.

6.9.1.1 Fast-Start Failover Metrics

When fast-start failover is enabled, these metrics will generate a critical alert on the new primary database (old standby) if a fast-start failover occurs.

6.9.1.2 Data Guard Performance Metrics

The Data Guard performance metrics provide alerts for performance related to redo log activity in the configuration.

6.9.1.3 Data Guard Status

The Data Guard Status metric checks the status of each database in the broker configuration and triggers a warning or critical alert if necessary.

6.9.2 Managing Data Guard Metrics

The example in this section describes Data Guard metrics and how to set up for notification through e-mail when a metric is triggered. Take the following steps to manage Data Guard metrics:

1. Set up to receive metric notification by e-mail.

2. View the All Metrics page.

3. Set or change metric thresholds for Data Guard thresholds.

4. View triggered metrics.

Step 1   Set up to receive metric notification by e-mail.

You can set up the Notification Methods to notify you through e-mail if any of the metrics are triggered. To set up Notification Methods, take the following steps:

a. Click Setup at the bottom of the Database Home page.

b. Click Notification Methods on the Setup page.

c. Set up the required mail server information.

See Also:
Oracle Enterprise Manager documentation and help for a complete description of Email Services

Step 2   View the All Metrics page.

You can view all of the metrics for Oracle Enterprise Manager, including Data Guard, by clicking All Metrics at the bottom of the Database Home page.

Figure 6-45 shows the All Metrics page for the primary database with the Data Guard metrics expanded.

Figure 6-45 Data Guard Metrics

Step 3   Set or change metric thresholds for Data Guard thresholds.

The following Data Guard metrics can be changed on the Metrics and Policy Settings page.

- Data Guard Fast-Start Failover

When Fast-Start Failover is enabled, these metrics will generate a critical alert on the new primary database (old standby) if a fast-start failover occurs:

- Fast-Start Failover Occurred: Indicates that a fast-start failover has occurred. The value is 0 if fast-start failover has not occurred, and 1 if fast-start failover has occurred.

- Fast-Start Failover SCN: Shows the SCN when a fast-start failover occurred. The fast-start failover SCN must be initialized to a value before the metric will alert.

- Fast-Start Failover Time: Shows the time when a fast-start failover occurred.

- Data Guard Performance

All charts on the Performance Overview page are represented by the following metrics.

- Apply Lag (seconds): Shows the approximate number of seconds the standby is behind the primary database.

- Estimated Failover Time (seconds): The approximate number of seconds required to fail over to this standby database. This accounts for the startup time, if necessary, plus the remaining time required to apply all the available redo on the standby. If a bounce is not required, it is only the remaining apply time.

- Redo Apply Rate (KB/second): Displays the Redo Apply Rate in KB/second on this standby database.

- Transport Lag (seconds): Shows the approximate number seconds of redo not yet available on the standby database.

- Data Guard Status

If the Data Guard Status metric contains Warning, a warning alert is triggered. If the metric contains Error, a critical alert is triggered.

See Also:
Oracle Enterprise Manager online Help for a information about setting metrics

Step 4   View triggered metrics.

If a metric condition is triggered or a threshold value is exceeded, an alert is issued. Click Data Guard Status, Data Guard Performance, or Data Guard Fast-Start Failover on the All Metrics page to view triggered metrics.

Figure 6-46 shows the Alert Log Errors page for the North_Sales database. It provides an example of what is shown when the Data Guard Fast-Start Failover metric triggers after a problem with the observer is detected in the configuration. The table shows the status of each database in the configuration. The status of the primary database shows the ORA-16820 error.

Figure 6-46 Alert Log Errors Page Showing the Observer Has Stopped

Because Email Services was set up, DBAs are also notified by an e-mail message.

After a metric condition is fixed, the metric is cleared automatically.

6.10 Scenario 10: Removing a Standby Database and Configuration

You can remove a standby database or broker configuration so that it is no longer controlled by the Data Guard broker.

6.10.1 Remove a Standby Database

Removing a standby database from Data Guard broker control does not permanently delete the database itself. This operation permanently removes the profile of the standby database from the broker configuration file.

By default, the standby destination is also removed from the primary database so that log files are no longer archived to that standby database.

Caution:

The Oracle9i Data Guard Manager default was to preserve the standby destination on the primary database.

To remove a standby database from the broker configuration, click Remove in the Standby Databases section of the Data Guard Overview page. Enterprise Manager will ask you to confirm that you really want to remove the standby database from the configuration. Click Yes to continue or No to cancel.

Figure 6-47 shows removing a standby database.

Figure 6-47 Removing a Standby Database

6.10.2 Remove the Data Guard Configuration

To remove the broker configuration, you must be connected to the configuration through the primary database. Click Remove Data Guard Configuration under the Additional Administration section. Enterprise Manager will ask you to confirm that you want to remove the configuration. Click Yes to continue or No to cancel.

Figure 6-48 shows removing a Data Guard broker configuration.

Figure 6-48 Removing a Data Guard Broker Configuration

When you choose this option, Enterprise Manager removes (deletes) the selected broker configuration permanently. When you permanently remove a configuration, the remove operation:

- Does not affect the underlying operations of the standby databases or log apply services if you check the box to preserve all standby destinations. Operations such as redo transport services and log apply services continue to run; however, these services are no longer manageable through Enterprise Manager.

- By default, all standby database profiles are removed from the broker configuration, and redo transport services to all standby databases in the configuration are stopped.

- Destroys all broker configuration profile information maintained for each database; the configuration is then unknown to the broker and can no longer be managed from Enterprise Manager.

Although the configuration information is not recoverable once you delete a broker configuration permanently, you can easily re-create the configuration with the Add Standby Database wizard.

Footnote Legend

Footnote 1: This documentation uses Enterprise Manager to refer to the Grid Control Web-based user interface for managing Data Guard broker configurations.

7 Scenarios Using the DGMGRL Command-Line Interface

This chapter provides several scenarios that show how to use the Data Guard command-line interface (DGMGRL) to create, manage, and monitor a broker configuration.

In addition to the prerequisites for getting started, this chapter describes the following scenarios:

- Scenario 1: Creating a Configuration

- Scenario 2: Setting Database Properties

- Scenario 3: Enabling the Configuration and Databases

- Scenario 4: Setting the Configuration Protection Mode

- Scenario 5: Enabling Fast-Start Failover and the Observer

- Scenario 6: Performing Routine Management Tasks

- Scenario 7: Performing a Switchover Operation

- Scenario 8: Performing a Manual Failover Operation

- Scenario 9: Monitoring a Data Guard Configuration

7.1 Prerequisites for Getting Started

One of the prerequisites for using DGMGRL is that a primary database and any standby databases must already exist. The DG_BROKER_START initialization parameter must be set to TRUE for all databases in the configuration. You must use a server parameter file with the broker (see Section 2.1 and Section 8.1.3).

Convert the initialization parameter files (PFILE) on both primary and standby databases into server parameter files (SPFILE), if necessary. Use the following SQL*Plus command:

CREATE SPFILE FROM PFILE='pfilename';

If an instance was not started with a server parameter file, then you must shut down the instance and restart it using the server parameter file.

After starting the Oracle instance, set the DG_BROKER_START=TRUE initialization parameter using the SQL ALTER SYSTEM statement. The parameter value will be saved in the server parameter file. The next time you start the Oracle instance, the broker is started automatically, and you do not need to issue the SQL ALTER SYSTEM statement again.

See Also:
Oracle Database Administrator's Guide for detailed information about creating server parameter files

The following assumptions are made for the scenarios in this chapter:

- TCP/IP is used to connect to primary and standby databases.

- The standby database has been created from backups of the primary database control files and datafiles as described in the Oracle Data Guard Concepts and Administration

- The scenarios in this chapter assume the following broker configuration:

- The configuration name is DRSolution.

- The database unique name (DB_UNIQUE_NAME) of the primary database is North_Sales.

- The database unique name (DB_UNIQUE_NAME) of the remote standby database is DR_Sales.

- The protection mode is maximum performance mode.

- There are no standby redo log files.

- The standby database is a physical standby database.

7.2 Scenario 1: Creating a Configuration

This section provides examples that create a broker configuration named DRSolution that includes a primary and standby database named North_Sales and DR_Sales.

The following steps show how to create a configuration and add one physical standby database.

Step 1   Invoke DGMGRL.

To start DGMGRL, enter DGMGRL at the command-line prompt on a system where Oracle Data Guard is installed:

$ dgmgrl

DGMGRL for Linux: Version 10.2.0.1.0 - ProductionCopyright (c) 2000, 2005, Oracle. All rights reserved.Welcome to DGMGRL, type "help" for information.

DGMGRL>

Step 2   Connect to the primary database.

Before you specify any command (other than the HELP, EXIT, or QUIT), you must first connect to the primary database using the DGMGRL CONNECT command.

The account from which you connect to the database (SYS in this example) must have SYSDBA privileges on the primary and standby databases.

Note:
You do not have to include AS SYSDBA on the CONNECT command because SYSDBA is the default setting for this command.

The following examples show two variations of the CONNECT command. Example 7-1 shows how to connect to the default database on the local system, and Example 7-2 includes the Oracle Net Services connect identifier (North_Sales.foo.com) to make a connection to a database located on a remote system.

Example 7-1 Connecting to the Primary Database on the Local System

DGMGRL> CONNECT sys/<password>;
Connected.

Example 7-2 Connecting to the Primary Database on a Remote System

DGMGRL> CONNECT sys/<password>@North_Sales.foo.com;
Connected.

Optionally, you can combine the steps shown in Example 7-1 and Example 7-2 by including the connection information on the command line:

$ DGMGRL sys/<password>@<connect identifier>

Step 3   Create the broker configuration.

To create the broker configuration, you first define the configuration including a profile for the primary database, which in this case is called North_Sales. In a later command, you will add a profile for the standby database, DR_Sales.

Note:
The names for the primary and standby databases must match their database unique names. Fetch these from their DB_UNIQUE_NAME initialization parameter as follows:
SQL> SHOW PARAMETER DB_UNIQUE_NAME;

Use the CREATE CONFIGURATION command to create the DRSolution configuration and define the primary database, North_Sales:

DGMGRL> CREATE CONFIGURATION 'DRSolution' AS
>  PRIMARY DATABASE IS 'North_Sales'
>  CONNECT IDENTIFIER IS North_Sales.foo.com;

DGMGRL returns the following information:

Configuration "DRSolution" created with primary database "North_Sales"

The name North_Sales is the value of this database's DB_UNIQUE_NAME initialization parameter.

Step 4   Show the configuration information.

Use the SHOW CONFIGURATION command to display a brief summary of the configuration:

DGMGRL> SHOW CONFIGURATION;

DGMGRL returns the following information:

Configuration
Name:                DRSolution
Enabled:             NO
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database

Current status for "DRSolution":
DISABLED

Step 5   Add a standby database to the configuration.

To add a standby database to the DRSolution configuration, use the ADD DATABASE command to create a broker configuration profile for the standby database.

The following command defines DR_Sales as a standby database, which is the standby database associated with the primary database called North_Sales:

DGMGRL> ADD DATABASE 'DR_Sales' AS
>  CONNECT IDENTIFIER IS DR_Sales.foo.com
>  MAINTAINED AS PHYSICAL;

DGMGRL returns the following information:

Database "DR_Sales" added

The name DR_Sales is the value of the database's DB_UNIQUE_NAME initialization parameter.

Use the SHOW CONFIGURATION command to verify that the DR_Sales database was added to the DRSolution configuration:

DGMGRL> SHOW CONFIGURATION;

DGMGRL returns the following information:

Configuration
Name:                DRSolution
Enabled:             NO
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database
DR_Sales     - Physical standby database

Current status for "DRSolution":
DISABLED

7.3 Scenario 2: Setting Database Properties

After you create the configuration with DGMGRL, you can set database properties at any time. For example, the following statements set the LogArchiveFormat and StandbyArchiveLocation properties for the DR_Sales standby database:

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogArchiveFormat'='log_%t_%s_%r_%d.arc';
Property "LogArchiveFormat" updated.

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'StandbyArchiveLocation'='/archfs/arch/';
Property "StandbyArchiveLocation" updated.

Use the SHOW DATABASE VERBOSE command to view all properties and their values for a database. The following example shows the properties for the DR_Sales database.

DGMGRL> SHOW DATABASE VERBOSE 'DR_Sales';

Database
Name:            DR_Sales
Role:            PHYSICAL STANDBY
Enabled:         NO
Intended State:  ONLINE
Instance(s):
DR_Sales1

Properties:
InitialConnectIdentifier        = 'DR_Sales.foo.com'
LogXptMode                      = 'ARCH'
Dependency                      = ''
DelayMins                       = '0'
Binding                         = 'OPTIONAL'
MaxFailure                      = '0'
MaxConnections                  = '0'
ReopenSecs                      = '300'
NetTimeout                      = '180'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/t, dbs/s2t'
LogFileNameConvert              = 'dbs/t, dbs/s2t'
FastStartFailoverTarget         = ''
StatusReport                    = '(monitor)'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
HostName                        = 'north.foo.com'
SidName                         = 'dr_sales1'
LocalListenerAddress            = '(ADDRESS=(PROTOCOL=TCP)(HOST=dr.foo.com)(PORT=1514))'
StandbyArchiveLocation          = '/archfs/arch'
AlternateLocation               = ''
LogArchiveTrace                 = '255'
LogArchiveFormat                = 'log_%t_%s_%r_%d.arc'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Current status for "DR_Sales":
DISABLED

If broker management of the database is enabled, setting a database property value causes the underlying parameter value to be changed in the corresponding database, and the value for the changed parameter is reflected in the server parameter file. Thus, if the database is shut down and restarted outside of Oracle Enterprise Manager and DGMGRL (such as from the SQL*Plus interface), the database uses the new parameter values from the updated server parameter file when it starts. However, you should not make changes to the redo transport services initialization parameters through SQL statements. Doing so will cause an inconsistency between the database and the broker.

Note:
The database properties are typically displayed in mixed-case (for example, LogArchiveFormat) typeface to help you visually differentiate database properties (from the corresponding initialization parameter, SQL statement, or PL/SQL procedure), which are typically documented in UPPERCASE typeface. However, the commands to manage properties are not case sensitive; you can issue commands in uppercase, lowercase, or mixed-case.

You can change a property if the database is enabled or disabled. However, if the database is disabled when you change a property, the change does not take effect until the database is enabled.

7.4 Scenario 3: Enabling the Configuration and Databases

So far, the DRSolution configuration is disabled, which means it is not under the control of the Data Guard broker. When you finish configuring the databases into a broker configuration and setting any necessary database properties, you must enable the configuration to allow the Data Guard broker to manage it. This brings the primary and standby databases online.

You can enable:

- The entire configuration, including all of its databases

- A standby database

Enable the entire configuration.

You can enable the entire configuration, including all of the databases, with the following command:

DGMGRL> ENABLE CONFIGURATION;
Enabled.

Show the configuration.

Use the SHOW command to verify that the configuration and its databases were successfully enabled and brought online:

DGMGRL> SHOW CONFIGURATION;

DGMGRL returns the following information:

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database
DR_Sales     - Physical standby database

Current status for "DRSolution"
SUCCESS

Enable the database.

This step is unnecessary except if the standby database was previously disabled with the DISABLE DATABASE command. Normally, enabling the configuration also enables the standby database.

DGMGRL> ENABLE DATABASE 'DR_Sales';
Enabled.

Show the database.

DGMGRL> SHOW DATABASE 'DR_Sales';

Database
Name:            DR_Sales
Role:            PHYSICAL STANDBY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
DR_Sales1

Current status for "DR_Sales":
SUCCESS

7.5 Scenario 4: Setting the Configuration Protection Mode

You can change the protection mode of the configuration at any time. However, it is best if you do this when there is no activity occurring in the configuration if you are moving to the maximum protection or maximum availability modes of data protection.

Note:
If the protection mode to be set is higher than what is currently set in the configuration, the broker automatically restarts the primary database.

This scenario sets the protection mode of the configuration to the MAXPROTECTION mode. Note that this protection mode requires that there be at least one standby database configured to use standby redo log files.

Step 1   Configure standby redo log files, if necessary.

Because you will be setting the protection mode to the MAXPROTECTION mode, it is important to ensure that sufficient standby redo log files are configured on the standby database.

See Also:
Oracle Data Guard Concepts and Administration for information about creating standby redo log files

Step 2   Set the LogXptMode property appropriately.

Use the EDIT DATABASE (property) command on the standby database to set the redo transport service that corresponds to the protection mode you plan to set. If the protection mode to be set is MAXPROTECTION, it is required that the redo transport service of at least one standby database is set to SYNC. For example:

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

The broker will not allow this command to succeed unless the standby database is configured with standby redo log files in the configuration.

Step 3   Change the overall protection mode for the configuration.

Use the EDIT CONFIGURATION command to upgrade the broker configuration to the MAXPROTECTION protection mode:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION;
Operation requires shutdown of instance "sales1" on database "North_Sales"

Shutting down instance "sales"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "sales1" on database "North_Sales"
Starting instance "sales1"...
ORACLE instance started.
Database mounted.

After you change the protection mode, the primary database instances automatically restart.

If the configuration is disabled when you enter this command, the actual protection mode change is not applied until you enable the configuration with the ENABLE CONFIGURATION command. The broker will not allow you to enable the configuration if it does not find a standby database in the configuration that can support the requirements of the protection mode.

Step 4   Verify the protection mode was changed.

Use the SHOW CONFIGURATION command to display the current protection mode for the configuration:

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxProtection
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database
DR_Sales     - Physical standby database

Current status for "DRSolution"
SUCCESS

See Also:
Section 4.6, "Managing Data Protection Modes"

7.6 Scenario 5: Enabling Fast-Start Failover and the Observer

You can enable fast-start failover from any site, including the observer site, while connected to any database in the broker configuration. Enabling fast-start failover does not trigger a failover. Instead, it allows the observer to begin observing the primary and standby databases and initiate a fast-start failover should conditions warrant a failover.

This section describes the steps to enable fast-start failover and the observer:

- Ensure standby redo logs are configured on all databases.

- Ensure the LogXptMode Property is set to SYNC.

- Specify the FastStartFailoverTarget property.

- Upgrade the protection mode to MAXAVAILABILITY, if necessary.

- Enable Flashback Database on the primary and standby databases, if necessary.

- Enable fast start failover.

- Start the observer.

- Verify the fast-start failover configuration.

Step 1   Ensure standby redo logs are configured on all databases.

Standby redo logs must be configured on the primary and standby databases. You must stop log apply services prior to configuring standby redo logs.

See Also:
Oracle Data Guard Concepts and Administration for instructions on configuring standby redo log files

Step 2   Ensure the LogXptMode Property is set to SYNC.

The LogXptMode property must be set to SYNC on the primary and target standby databases.

To set the redo transport service that corresponds to the protection mode you plan to set, use the EDIT DATABASE (property) command on the primary and target standby databases. For example, if the protection mode to be set is MAXPROTECTION, you must set the LogXptMode property to SYNC on the primary database and on at least one standby database, as shown in the following examples:

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

The broker does not allow these commands to succeed unless the databases are configured with standby redo log files.

Step 3   Specify the FastStartFailoverTarget property.

If you have two or more standby databases, set up the FastStartFailoverTarget property on the primary database and the target standby database to point to each other. For example:

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY FastStartFailoverTarget='DR_Sales';
Property "FastStartFailoverTarget" updated

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY FastStartFailoverTarget='North_Sales';
Property "FastStartFailoverTarget" updated

Step 4   Upgrade the protection mode to MAXAVAILABILITY, if necessary.

If it is necessary to upgrade the protection mode, use the following DGMGRL EDIT CONFIGURATION command. For example:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

Operation requires shutdown of instance "sales1" on database "North_Sales"
Shutting down instance "sales1"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "sales1" on database "North_Sales"
Starting instance "sales1"...
ORACLE instance started.
Database mounted.

Step 5   Enable Flashback Database on the primary and standby databases, if necessary.

If it is not already enabled on the primary and standby databases, enable Flashback Database by issuing the following statements on each database:

ALTER SYSTEM SET UNDO_RETENTION=3600 SCOPE=SPFILE;
ALTER SYSTEM SET UNDO_MANAGEMENT='AUTO' SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
SHOW PARAMETER UNDO;
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE FLASHBACK ON;
ALTER DATABASE OPEN;

Ensure the UNDO_RETENTION and DB_FLASHBACK_RETENTION_TARGET initialization parameters are set to sufficiently large values so that reinstatement is still possible after a prolonged outage.

Step 6   Enable fast start failover.

You can enable fast-start failover while connected to any database system in the broker configuration, including on the observer computer. For example:

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

Step 7   Start the observer.

Start the observer by logging into the observer computer and running DGMGRL. Connect to the configuration and then issue the START OBSERVER command. Note that the command does not return; that is you will not get DGMGRL prompt after issuing the command.

DGMGRL> CONNECT sys/password@North_Sales.foo.com;
DGMGRL> START OBSERVER;
Observer started

When starting the observer interactively, Oracle recommends that connection credentials be supplied as a command parameter to the DGMGRL CONNECT command, as shown in the example, rather than as a command line parameter to the DGMGRL command. This practice prevents other users on the system from using a utility (for example, the UNIX ps utility) to display the connection credentials.

When starting the observer from a script, Oracle recommends that you use a method that supports connection as '/', so that connection credentials do not have to be embedded within the script. The Oracle Wallet, described in the Oracle Database Advanced Security Administrator's Guide, is one such method. If you choose to use the Oracle Wallet, be sure to add a default password to the wallet and to set the value of this default password to that of the SYS password on the primary database.

Step 8   Verify the fast-start failover configuration.

Use the SHOW CONFIGURATION command to display the readiness of the fast-start failover configuration:

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxAvailability
Fast-Start Failover: ENABLED
Databases:
North_Sales - Primary database
DR_Sales    - Physical standby database
- Fast-Start Failover target

Fast-Start Failover
Threshold: 30 seconds
Observer:  observer.foo.com

Current status for "DRSolution":
SUCCESS

In the example, note that the FastStartFailoverThreshold value is 30 seconds. This is the default value.

7.7 Scenario 6: Performing Routine Management Tasks

There may be situations in which you want to change the state or properties of the databases in a broker configuration to perform routine maintenance on one or more databases. You might also need to temporarily disable broker management of databases in a configuration.

7.7.1 Changing Properties and States

As you monitor the configuration, you might need to dynamically modify the states of the databases or their properties. The following sections show how to change the state or properties of the databases in the configuration.

7.7.1.1 Alter a Database Property

You can modify the values of database properties at any time—if the database is enabled, disabled, online, or offline.

Example 7-3 shows how to use the EDIT DATABASE command to change the LogArchiveTrace property to the value 127 for the North_Sales database.

Example 7-3 Altering a Database Property

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogArchiveTrace'='127';

DGMGRL returns the following message to indicate that the LogArchiveTrace property was updated successfully in the Data Guard configuration file:

Property "LogArchiveTrace" updated

If the configuration is currently disabled, the database does not use the new property value until you enable the broker configuration with the ENABLE CONFIGURATION command.

7.7.1.2 Alter the State of a Standby Database

You might want to use your physical standby database temporarily for reporting applications. To change the state of the standby database to read-only, enter the EDIT DATABASE command as shown in Example 7-4.

Example 7-4 Altering a Standby Database State

DGMGRL> EDIT DATABASE 'DR_Sales' SET STATE='READ-ONLY';
Succeeded.

Log files are still being received when you put the physical standby database in the read-only state. The broker stops Redo Apply from applying the redo data to the standby database.

7.7.1.3 Alter the State of a Primary Database

You might want to stop the transmittal of log files to the standby database. To change the state of the primary database to accommodate this, use the EDIT DATABASE North_Sales SET STATE=LOG-TRANSPORT-OFF command. You can also set the primary database OFFLINE, which effectively shuts down the primary database and disables the broker from managing the configuration (shown in Example 7-5).

Example 7-5 Altering a Primary Database State

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='OFFLINE';

DGMGRL returns the following message to indicate the command was successfully executed:

Operation requires shutdown of instance "sales1" on database "North_Sales"

Shutting down instance "sales1"...
Database closed.
Database dismounted.
ORACLE instance shut down.

To change the primary state back to ONLINE, you must start the primary database.

7.7.2 Disabling the Configuration and Databases

When you disable the broker configuration or any of its databases, you are disabling the broker's management of those objects and are effectively removing your ability to use DGMGRL to manage and monitor the disabled object. However, disabling the broker's management of a broker configuration does not affect the actual operation of the underlying Data Guard configuration or the databases. For example, the redo transport services and log apply services in the Data Guard configuration continue to function unchanged, but you can no longer manage them with DGMGRL.

7.7.2.1 Disable a Configuration

You must use the DISABLE CONFIGURATION command to disable management of the entire broker configuration including the primary database as shown in Example 7-6.

Example 7-6 Disabling the Configuration and Primary Database

DGMGRL> DISABLE CONFIGURATION;

The only way to disable broker management of the primary database is to use the DISABLE CONFIGURATION command; the DISABLE DATABASE command only disables management of a standby database.

Note:
If you disable management of a configuration while connected to the standby database, you must connect to the primary database to reenable the configuration.

Disabling the broker's management of an object does not remove or delete its profile from the broker configuration file. You can reenable your ability to use DGMGRL (or Enterprise Manager) to manage the object by entering the appropriate ENABLE CONFIGURATION or ENABLE DATABASE command.

7.7.2.2 Disable a Standby Database

You use the DISABLE DATABASE command when you temporarily do not want the broker to manage and monitor a standby database.

You can explicitly disable broker management of a standby database to prevent it from being brought online when the rest of the configuration is brought online. Example 7-7 shows how to disable the DR_Sales standby database.

Example 7-7 Disabling a Standby Database

DGMGRL> DISABLE DATABASE 'DR_Sales';
Disabled.

Note:
If you disable management of a standby database while connected to that standby database, you must connect to the primary database or another enabled standby database to reenable broker-management of the standby database.

Caution:

If you disable broker management of a standby database in the broker configuration, that standby database cannot be used by the broker as a failover target in the event of loss of the primary database.

When running in either the maximum protection or maximum availability mode, the broker prevents you from disabling the last standby database that supports the protection mode.

7.7.3 Removing the Configuration or a Standby Database

When you use either the REMOVE CONFIGURATION or REMOVE DATABASE command, you effectively delete the configuration or standby database profile from the broker configuration file, removing the ability of the Data Guard broker to manage the configuration or the standby database, respectively.

A remove operation does not remove or delete the actual Data Guard configuration underneath, nor does it affect the operation of the actual Data Guard configuration and its databases.

Caution:
After you use the REMOVE CONFIGURATION or REMOVE DATABASE command, you cannot recover the configuration or database profile that was deleted from the broker configuration file. You must go through the steps in Section 7.2 as necessary, to create a broker configuration that can be managed with DGMGRL (or the Enterprise Manager).

Step 1   Remove a standby database from the configuration.

When you use the REMOVE DATABASE command, broker management and monitoring of the database ceases and the database's profile is deleted from the broker configuration file:

DGMGRL> SHOW CONFIGURATION;

Configuration
Name:                DRSolution
Enabled:             NO
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database
DR_Sales     - Physical standby database

Current status for "DRSolution":
SUCCESS

DGMGRL returns the following message to indicate the command successfully removed the DR_Sales database information from the Data Guard configuration file:

DGMGRL> REMOVE DATABASE 'DR_Sales';
Removed database "DR_Sales" from the configuration

DGMGRL> SHOW CONFIGURATION;
Configuration
Name:                DRSolution
Enabled:             NO
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database

Current status for "DRSolution":
SUCCESS

When running in either the maximum protection or maximum availability mode, the broker prevents you from deleting the last standby database that supports the protection mode.

Step 2   Remove the broker configuration.

Use the following command to remove the entire configuration from management and monitoring by the broker:

DGMGRL> REMOVE CONFIGURATION;

Note:
You cannot remove the configuration if fast-start failover is enabled.

DGMGRL returns the following message to indicate the command successfully removed all of the configuration information from the Data Guard configuration file:

Removed configuration

DGMGRL> SHOW CONFIGURATION;
Error: ORA-16532: Data Guard broker configuration does not exist

Configuration details cannot be determined by DGMGRL

7.8 Scenario 7: Performing a Switchover Operation

You can switch the role of the primary database and a standby database using the SWITCHOVER command. Before you issue the SWITCHOVER command, you must ensure:

- The state of the primary and standby databases are online.

- All participating databases are in good health, without any errors or warnings present.

- The standby database properties were set on the primary database, so that the primary database can function correctly when transitioning to a standby database (shown in the following examples in boldface type).

- Standby redo log files on the primary database are set up, and the LogXptMode property is set to SYNC if the configuration protection mode is maximum availability or maximum protection.

- The observer is running if fast-start failover is enabled.

See Also:
Oracle Data Guard Concepts and Administration

Step 1   Check the primary database.

Use the SHOW DATABASE VERBOSE command to check the state, health, and properties of the primary database, as follows:

DGMGRL> SHOW DATABASE VERBOSE 'North_Sales'

Database
Name:            North_Sales
Role:            PRIMARY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
sales1

Properties:
InitialConnectIdentifier        = 'North_Sales.foo.com'
LogXptMode                      = 'SYNC'
Dependency                      = ''
DelayMins                       = '0'
Binding                         = 'OPTIONAL'
MaxFailure                      = '0'
MaxConnections                  = '0'
ReopenSecs                      = '30'
NetTimeout                      = '180'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/s2t, dbs/t'
LogFileNameConvert              = 'dbs/s2t, dbs/t'
FastStartFailoverTarget         = ''
StatusReport                    = '(monitor)'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
HostName                        = 'north.foo.com'
SidName                         = 'sales1'
LocalListenerAddress            = '(ADDRESS=(PROTOCOL=TCP)(HOST=north.foo.com)(PORT=1514))'
StandbyArchiveLocation          = '/archfs/arch/'
AlternateLocation               = ''
LogArchiveTrace                 = '127'
LogArchiveFormat                = 'r_%d_%t_%s_%r.arc'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Current status for "North_Sales":
SUCCESS

In particular, you should examine the boldface properties and the current status of the primary database. See Chapter 4 for information about managing databases.

Step 2   Check the standby database that is the target of the switchover.

Use the SHOW DATABASE VERBOSE command to check the state, health, and properties of the standby database that is the target of the switchover. For example:

DGMGRL> SHOW DATABASE VERBOSE 'DR_Sales'

Database
Name:            DR_Sales
Role:            PHYSICAL STANDBY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
dr_sales1

Properties:
InitialConnectIdentifier        = 'DR_Sales.foo.com'
LogXptMode                      = 'SYNC'
Dependency                      = ''
DelayMins                       = '0'
Binding                         = 'OPTIONAL'
MaxFailure                      = '0'
MaxConnections                  = '0'
ReopenSecs                      = '30'
NetTimeout                      = '180'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/t, dbs/s2t'
LogFileNameConvert              = 'dbs/t, dbs/s2t'
FastStartFailoverTarget         = ''
StatusReport                    = '(monitor)'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
HostName                        = 'dr.foo.com'
SidName                         = 'dr_sales1'
LocalListenerAddress            = '(ADDRESS=(PROTOCOL=TCP)(HOST=dr.foo.com)(PORT=1514))'
StandbyArchiveLocation          = '/archfs/arch'
AlternateLocation               = ''
LogArchiveTrace                 = '127'
LogArchiveFormat                = 'db3r_%d_%t_%s_%r.arc'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Current status for "DR_Sales":
SUCCESS

In particular, you should examine the current status of the database.

Step 3   Issue the switchover command.

Issue the SWITCHOVER command to swap the roles of the primary and standby databases. The following example shows how the broker automatically shuts down and restarts the two participating databases as a part of the switchover. (See the usage notes in Section 8.1.3 for information about how to set up the broker environment so that DGMGRL can automatically restart the primary and standby databases for you.)

DGMGRL> SWITCHOVER TO DR_Sales;
Performing switchover NOW, please wait...
Operation requires shutdown of instance "sales1" on database "North_Sales"
Shutting down instance "sales1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires shutdown of instance "dr_sales1" on database "DR_Sales"
Shutting down instance "dr_sales1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "sales1" on database "North_Sales"
Starting instance "sales1"...
ORACLE instance started.
Database mounted.
Operation requires startup of instance "dr_sales1" on database "DR_Sales"
Starting instance "dr_sales1"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "DR_Sales"

After the switchover completes, use the SHOW CONFIGURATION and SHOW DATABASE commands to verify that the switchover operation was successful.

Step 4   Show the configuration.

Issue the SHOW CONFIGURATION command to verify that the switchover was successful.

DGMGRL> SHOW CONFIGURATION;

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxProtection
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Physical standby database
DR_Sales     - Primary database

Current status for "DRSolution":
SUCCESS

7.9 Scenario 8: Performing a Manual Failover Operation

You invoke a failover operation in response to an emergency situation, usually when the primary database cannot be accessed or is unavailable. See Section 5.2 before you fail over to decide which standby database should be the target of the failover. The following scenario describes a failover to the remote database called DR_Sales.

Note:
If fast-start failover is enabled, you can perform a manual failover only to the standby database that was specified as the target of a fast-start failover and only when the observer is running.
Performing a manual failover in this case can be useful if the target standby database is in the SUSPEND state or if the FastStartFailoverThreshold property is set to a very high value. In this case, first disable fast-start failover using the FORCE option on the target standby database before performing manual failover. See Section 5.5.4, "Disabling Fast-Start Failover" for more information about the FORCE option.

Step 1   Connect to the target standby database.

To perform the failover operation, you must connect to the standby database to which you want to fail over using the SYSDBA username and password of that database. For example:

DGMGRL> CONNECT sys/knl_test7@DR_Sales.foo.com
Connected.

Step 2   Issue the failover command.

Now you can issue the failover command to make the target standby database the new primary database for the configuration. Note that after the failover completes, the original primary database cannot be used as a standby database of the new primary database unless it is reenabled (as described in Section 5.4.3).

If the target of the failover is a physical standby database, the failover behavior differs depending on whether or not the physical standby database had ever been opened read-only:

- If failover occurs to a physical standby that had been opened read-only, the database must be shut down and restarted as the new primary database.

The following example shows how the broker automatically shuts down and restarts the new primary database as a part of the failover:

DGMGRL> FAILOVER TO "DR_Sales";
Performing failover NOW. Please wait...
Operation requires shutdown of instance "dr_sales1" on database
"DR_Sales".
Shutting down instance "dr_sales1"...
database not mounted
ORACLE instance shut down.
Operation requires startup of instance "dr_sales1" on database "DR_Sales".
Starting instance "dr_sales1"...
ORACLE instance started.
Database mounted.
Failover succeeded. New primary is "DR_Sales"

See Also:
(The usage notes in Section 8.1.3 for information about how to set up the broker environment so that DGMGRL can automatically restart the new primary database

- If failover occurs to a physical standby that has never been opened read-only, then the database does not need to be restarted. For example:

DGMGRL> FAILOVER TO 'DR_Sales';
Performing failover NOW, please wait...
Failover succeeded, new primary is "DR_Sales"

Step 3   Show the configuration.

Issue the SHOW CONFIGURATION command to verify the failover.

DGMGRL> SHOW CONFIGURATION;

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Physical standby database (disabled)
DR_Sales     - Primary database

Current status for "DRSolution":
SUCCESS

Step 4   Show the database.

Issue the SHOW DATABASE command to see that the former (failed) primary database was disabled by the broker as a consequence of the failover. It must be reenabled (as described in Section 5.4.3).

DGMGRL> SHOW DATABASE 'North_Sales';

Database
Name:            North_Sales
Role:            PHYSICAL STANDBY
Enabled:         NO
Intended State:  ONLINE
Instance(s):
sales1

Current status for "North_Sales":
Error: ORA-16661: the standby database needs to be reinstated

7.10 Scenario 9: Monitoring a Data Guard Configuration

The scenario in this section demonstrates how to use the SHOW command and monitorable database properties to identify and resolve a failure situation.

Step 1   Check the configuration status.

The status of the broker configuration is an aggregated status of all databases and instances in the broker configuration. You can check the configuration status first to determine whether or not any further action needs to be taken. If the configuration status is SUCCESS, everything in the broker configuration is working fine. However, if you see the following error, it means something is wrong in the configuration:

DGMGRL> SHOW CONFIGURATION;
Configuration
Name:                DRSolution
Enabled:             NO
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database
DR_Sales     - Physical standby database

Current status for "DRSolution":
Warning: ORA-16607: one or more databases have failed

In this case, you need to continue on to Step 2 to determine the actual failure.

Step 2   Check the database status.

To identify which database has the failure, you need to go through all of the databases in the configuration one by one. In this example, the error happens to be on the primary database North_Sales:

DGMGRL> SHOW DATABASE 'North_Sales';

The command returns the following output:

Database
Name:            North_Sales
Role:            PRIMARY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
sales1

Current status for "North_Sales":
Error: ORA-16810: multiple errors or warnings detected for the database

Step 3   Check the monitorable property StatusReport.

When you see message ORA-16810, you can use the monitorable property StatusReport to identify each of the errors or warnings:

DGMGRL> SHOW DATABASE 'North_Sales' 'StatusReport';
STATUS REPORT
INSTANCE_NAME   SEVERITY ERROR_TEXT
sales1      ERROR ORA-16737: the redo transport service for
standby "DR_Sales" has an error
sales1    WARNING ORA-16714: the value of property
LogArchiveTrace is inconsistent with the database setting
sales1    WARNING ORA-16715: log transport related property
ReopenSecs of standby "DR_Sales" is inconsistent

Step 4   Check the monitorable property LogXptStatus.

You see error ORA-16737 in the previous status report in Step 3. To identify the exact log transport error, you can use monitorable property LogXptStatus:

DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus';
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME               STATUS
sales1             DR_Sales ORA-12541: TNS:no listener

Now you know the exact reason why redo transport services failed. To fix this error, start the listener for the physical standby database DR_Sales.

Step 5   Check the monitorable property InconsistentProperties.

You also see warning ORA-16714 reported in Step 3. To identify the inconsistent values for property LogArchiveTrace, you can use monitorable property InconsistentProperties:

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentProperties';

INCONSISTENT PROPERTIES
INSTANCE_NAME   PROPERTY_NAME    MEMORY_VALUE    SPFILE_VALUE    BROKER_VALUE
sales1   LogArchiveTrace           255            0            0

It seems that the current database memory value (255) is different from both the server parameter file (SPFILE) value (0) and Data Guard broker's property value (0). If you decide the database memory value is correct, you can update Data Guard broker's property value using the following command:

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'LogArchiveTrace'=255;
Property "LogArchiveTrace" updated

In the previous command, Data Guard broker also updates the spfile value for you so that value for LogArchiveTrace is kept consistent.

Step 6   Check the monitorable property InconsistentLogXptProps.

Another warning you see in the status report returned in Step 3 is ORA-16715. To identify the inconsistent values for the redo transport property, ReopenSecs, you can use monitorable property InconsistentLogXptProps:

DGMGRL> SHOW DATABASE 'North_Sales' 'InconsistentLogXptProps';

INCONSISTENT LOG TRANSPORT PROPERTIES
INSTANCE_NAME    STANDBY_NAME   PROPERTY_NAME    MEMORY_VALUE    BROKER_VALUE
sales1        DR_Sales      ReopenSecs             600             300

The current database memory value (600) is different from the Data Guard broker's property value (300). If you think the broker's property value is correct, you can fix the inconsistency by re-editing the property of the standby database with the same value, as shown in the following example:

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'ReopenSecs'=300;
Property "ReopenSecs" updated

You can also reenable the standby database or reset the primary database state to ONLINE to fix the inconsistency, but re-editing the property is the simplest.

8 Data Guard Command-Line Interface Reference

The Data Guard command-line interface (DGMGRL) enables you to manage a Data Guard broker configuration and its databases directly from the command line, or from batch programs or scripts. You can use the Data Guard command-line interface as an alternative to Oracle Enterprise Manager for managing a Data Guard configuration.

This chapter provides reference information for the Data Guard command-line interface.

8.1 Starting the Data Guard Command-Line Interface

To run DGMGRL, you must have SYSDBA privileges.

Start the command-line interface by entering DGMGRL at the command-line prompt on a system where Oracle is installed:

% dgmgrl

DGMGRL for Linux: Version 10.2.0.1.0 - ProductionCopyright (c) 2000, 2005, Oracle. All rights reserved.Welcome to DGMGRL, type "help" for information.

DGMGRL>

8.1.1 DGMGRL Optional Parameters

You can supply optional parameters on the command line to indicate how you want the Data Guard command-line interface to display output such as command prompts, banners, and messages.

Additionally, a single command mode is available. In this mode, DGMGRL executes one command and exits upon the completion of the command. The exit code is the result of the command. If the exit code is 0, the command completed successfully. Otherwise, there was an error.

The command line of DGMGRL appears as follows:

% DGMGRL [<options>] [<logon> [<command>] ]

Specify any of the following keywords when you invoke the DGMGRL command-line interface:

- <options> can be one of the following choices:

- -echo

Displays command input and output to the default display device. If you do not use this parameter, only the output from the command is displayed.

- -logfile <file-spec> "<dgmgrl-command>"

Specifies a file into which you can capture the actions of the DGMGRL command-line interface. This is particularly useful when DGMGRL is being invoked to serve as the fast-start failover observer. See the "START OBSERVER" command for more information.

- -silent

Suppresses the display of the DGMGRL (DGMGRL>) command prompt on your default display device. This option is useful if you are directing the command output to a file or to another display tool.

- <logon> is:

- username/password [@connect-identifier]

The username and password used to connect to the database. The connect-identifier is a fully specified connect descriptor or a name to be resolved by an Oracle naming method (for example, TNS). The connect-identifier is optional.

- <command> is a single command.

For example:

% DGMGRL sys/knl_test7@primary "show database 'North_Sales'"

The following subsections specify the command format that you enter at the DGMGRL> command prompt.

8.1.2 DGMGRL Command Format and Parameters

The DGMGRL commands allow you to create and maintain one broker configuration at a time. A broker configuration can consist of a primary database and up to 9 standby databases.

After you invoke the command-line interface, you can enter any of the DGMGRL commands listed in Table 8-1. Each command and its associated parameters are described in detail in later sections of this chapter.

Table 8-1 Summary of DGMGRL Commands

Command

Effect

ADD DATABASE

Adds a new standby database profile to the existing broker configuration.

CONNECT

Connects to the specified database using the specified username.

CREATE CONFIGURATION

Creates a broker configuration and creates and adds a primary database profile to the configuration.

DISABLE CONFIGURATION

Disables broker management of a configuration so that the configuration and all of its databases are no longer managed by the broker.

DISABLE DATABASE

Disables broker management of the named standby database.

DISABLE FAST_START FAILOVER

Disables fast-start failover.

EDIT CONFIGURATION (Property)

Changes the value of a property for the broker configuration.

EDIT CONFIGURATION (Protection Mode)

Changes the current protection mode setting for the broker configuration.

EDIT DATABASE (Property)

Changes the value of a property for the named database.

EDIT DATABASE (Rename)

Changes the name used by the broker to refer to the specified database.

EDIT DATABASE (State)

Changes the state of the specified database.

EDIT INSTANCE (AUTO PFILE)

Sets the name of the initialization parameter file for the specified instance.

EDIT INSTANCE (Property)

Changes the value of a property for the specified instance.

ENABLE CONFIGURATION

Enables broker management of the broker configuration and all of its databases.

ENABLE DATABASE

Enables broker management of the specified database.

ENABLE FAST_START FAILOVER

Enables the broker to automatically failover from the primary database to a target standby database.

EXIT

Exits the Data Guard command-line interface.

FAILOVER

Performs a database failover operation in which the standby database, to which DGMGRL is currently connected, fails over to the role of primary database.

HELP

Displays online help for the Data Guard command-line interface.

QUIT

Quits the Data Guard command-line interface.

REINSTATE DATABASE

Reinstates the database after a failover.

REMOVE CONFIGURATION

Removes the broker configuration including all of its database profiles from the broker configuration file.

REMOVE DATABASE

Removes the specified standby database profile from the broker configuration.

REMOVE INSTANCE

Removes knowledge of an instance from an existing database profile in the broker configuration.

SHOW CONFIGURATION

Displays information about the broker configuration.

SHOW DATABASE

Displays information about the specified database.

SHOW INSTANCE

Displays information about the specified instance.

SHUTDOWN

Shuts down a currently running Oracle database.

START OBSERVER

Starts the observer.

STARTUP

Starts an Oracle instance with the same options as SQL*Plus, including mounting and opening a database.

STOP OBSERVER

Stops the observer.

SWITCHOVER

Performs a switchover operation in which the current primary database becomes a standby database, and the specified standby database becomes the primary database.

Note:
Existing Oracle9i command-line scripts are supported in Oracle Database 10g for non-RAC databases. See Appendix A for information about deprecated commands.

8.1.3 DGMGRL Command Usage Notes

To use DGMGRL, the following must be true:

- The DG_BROKER_START dynamic initialization parameter is set to TRUE.

- To enable broker operations that require restarting instances without manual intervention, Oracle Net Services must be configured on each of the hosts that contain the primary and standby database instances. Specifically, the listener.ora file must contain static configuration information about the instance. The GLOBAL_DBNAME attribute must be set to db_unique_name_DGMGRL.db_domain. See Section 2.2 for additional information.

- The net service name, if used, must be resolvable from any of the hosts in the configuration.

See Also:
Section 2.1 for information about the listener prerequisites. Chapter 7 for more information about preparing and starting Oracle Data Guard broker. See the Oracle Database Administrator's Guide for more information about setting up the network files and listener on the standby database.

- You must have SYSDBA privileges to use the Data Guard command-line interface. Do not include AS SYSDBA on the CONNECT command because SYSDBA is the default setting for this command.

- The password for SYS needs to be identical on all databases, and all databases should use the remote password file (either SHARED or EXCLUSIVE).

See Also:
Oracle Data Guard Concepts and Administration for information about passwords

- If you specify more than one option on the command, you can specify the options in any order.

- A semicolon is required at the end of each DGMGRL command.

- Characters specified in a DGMGRL command string value are interpreted as lowercase characters, unless enclosed in double (") or single (') quotation marks. For example, database and DatAbaSe are equivalent, but "database" and "DatAbaSe" are not.

- You can use the backslash (\) to escape a single quotation mark ('), a double quotation mark ("), and the backslash character (\) itself if these characters appear in a character string.

- Some operations on a broker configuration may require that one or more databases be shut down and restarted. In most cases, DGMGRL will automatically shut down and restart a given database for you if the following are true:

- The instance-name is the SID (this applies to Enterprise Manager as well as DGMGRL).

- The broker must be able to connect to the database using the username and password given in the last CONNECT command, even if the last CONNECT command was used to connect to another database. Thus, the remote password file for the database must contain the username and password given in the last CONNECT command.

See Also:
Oracle Database Administrator's Guide for more information about setting up remote password files and the default location of the PFILE and SPFILE initialization parameter files.

Command Examples

Example 1

This example demonstrates how to connect to the DGMGRL command-line interface on a local system.

% dgmgrl

DGMGRL for Linux: Version 10.2.0.1.0 - ProductionCopyright (c) 2000, 2005, Oracle. All rights reserved.Welcome to DGMGRL, type "help" for information.

DGMGRL> CONNECT sys/change_on_install;
Connected.

Example 2

This example demonstrates how to connect to the Data Guard (DGMGRL) command-line interface on a remote system.

DGMGRL> CONNECT sys/change_on_install@remote-stby;
Connected.

8.2 Stopping the Data Guard Command-Line Interface

When you are done working with the command-line interface and want to return to the operating system, enter the EXIT or QUIT command at the DGMGRL command prompt. For example:

DGMGRL> EXIT;

ADD DATABASE

Creates a new standby database profile and adds it to the existing broker configuration. The standby database type (physical or logical) is specified by the MAINTAINED AS clause.

Format

ADD DATABASE database-name AS

CONNECT IDENTIFIER IS connect-identifier

MAINTAINED AS {PHYSICAL | LOGICAL};

Command Parameters

database-name

The name that will be used by the broker to refer to this standby database. It must match (case-insensitive) the value of the corresponding database DB_UNIQUE_NAME initialization parameter.

connect-identifier

A fully specified connect descriptor or a name to be resolved by an Oracle Net Services naming method (for example, TNS).

Usage Notes

- You must connect to the primary database to issue this command.

- The broker uses the specified connect-identifier to communicate with the specified database from other databases. Therefore, you must ensure that the connect-identifier can be used to address the specified database from all databases in your configuration. For example, if you use tnsnames.ora files to resolve the connect-identifier, you must ensure it will be resolved to the same connect descriptor in all tnsnames.ora files and the resulting connect descriptor can be used to reach the database specified in this ADD DATABASE command.

- If the connection cannot be made, the broker does not add the new database to the configuration.

Command Example

Example 1

The following example shows how to add a database named DR_Sales.

DGMGRL> ADD DATABASE DR_Sales AS
> CONNECT IDENTIFIER IS DR_Sales.foo.com
> MAINTAINED AS PHYSICAL;
Database "DR_Sales" added

CONNECT

Connects a given username to the specified database.

Format

CONNECT username/password [@connect-identifier];

Command Parameters

username/password

Represents the username and password with which you want to connect to the database.

connect-identifier

Consists of the Oracle Net Services connect identifier of the database to which you want to connect. The exact syntax depends upon the Oracle Net Services communications protocol your Oracle installation uses.

Usage Notes

- The username and password must be valid for the database to which you are trying to connect. The username you specify must have the SYSDBA privilege. You do not have to include AS SYSDBA on the CONNECT command because SYSDBA is the default setting for this command.

- If the CONNECT command returns an error, check to see that you specified a valid connect-identifier.

Command Examples

Example 1

This example connects to the default database on the local system.

DGMGRL> CONNECT sys/change_on_install;
Connected.

Example 2

This example connects to a remote database whose connect-identifier is prmy.

DGMGRL> CONNECT sys/change_on_install@prmy;
Connected.

Example 3

This example connects to a database using CONNECT '/' so that connection credentials are not visible on the command line:

DGMGRL> CONNECT /@prmy;

You must set up Oracle Wallet to use CONNECT '/'. By setting up Oracle Wallet, you can write a script to securely start and run the observer as a background job without specifying database credentials in the script.

See Also:
Oracle Database Advanced Security Administrator's Guide for more information about Oracle Wallet

CREATE CONFIGURATION

Creates a new broker configuration, and creates and adds a primary database profile to the configuration.

Format

CREATE CONFIGURATION configuration-name AS

PRIMARY DATABASE IS database-name

CONNECT IDENTIFIER IS connect-identifier;

Command Parameters

configuration-name

A user-friendly name for the configuration you are creating. Valid names contain any alphanumeric characters. If spaces are included in the name, the name must be enclosed in double or single quotation marks. The name must consist of 30 or fewer bytes.

database-name

The name that will be used by the broker to refer to the primary database. It must match (case-insensitive) the value of the corresponding database DB_UNIQUE_NAME initialization parameter.

connect-identifier

A fully specified connect descriptor or a name to be resolved by an Oracle Net Services naming method (for example, TNS).

Usage Notes

- A broker configuration is a named collection of one or more databases that you want to manage as a group. You must specify a value for each of the command parameters. There are no default values.

- You must connect to the primary database to issue this command.

- The broker uses the specified connect-identifier to communicate with the specified database from other databases. Therefore, you must ensure that the connect-identifier can be used to address the specified database from all databases in your configuration. For example, if you use tnsnames.ora files to resolve the connect-identifier, you must ensure it will be resolved to the same connect descriptor in all tnsnames.ora files and the resulting connect descriptor can be used to reach the primary database specified in this CREATE CONFIGURATION command.

- To add standby databases after you create the broker configuration, use the ADD DATABASE command.

Command Example

Example 1

The following example creates a new broker configuration named DRSolution with a primary database named North_Sales.

DGMGRL> CREATE CONFIGURATION 'DRSolution' AS
> PRIMARY DATABASE IS 'North_Sales'
> CONNECT IDENTIFIER IS North_Sales.foo.com;
Configuration "DRSolution" created with primary database "North_Sales"

DISABLE CONFIGURATION

Disables broker management of a configuration so that the configuration and all of its databases are no longer managed by the broker.

Format

DISABLE CONFIGURATION;

Command Parameters

None.

Usage Notes

- A disabled configuration and all of its constituent databases are no longer managed by the broker.

- The only way to disable broker management of the primary database is to use the DISABLE CONFIGURATION command.

- This command does not remove the broker configuration. See the REMOVE CONFIGURATION command for more information about removing the configuration.

- You can edit database properties and modify the configuration's protection mode while the configuration is disabled. However, any changes made to properties or to the protection mode will not take effect until the configuration is enabled.

- This command cannot be executed if fast-start failover is enabled.

Command Example

Example 1

The following example disables management of the broker configuration and all of its databases.

DGMGRL> DISABLE CONFIGURATION;
Disabled.

DISABLE DATABASE

Disables broker management of the named standby database. This means that broker directed state changes will be disallowed for this database, and the broker will not monitor the database for health status or for monitorable property values.

Format

DISABLE DATABASE database-name;

Command Parameter

database-name

Name of the standby database to be disabled.

Usage Notes

- You cannot specify the name of a primary database.

- Use the DISABLE CONFIGURATION command to disable the primary and all standby databases.

- If the sole standby database is disabled, you have no failover option. This standby database is not viable for failover until it is reenabled.

- This command cannot be executed if fast-start failover is enabled.

Command Example

Example 1

The following example shows how to disable a database named DR_Sales.

DGMGRL> DISABLE DATABASE 'DR_Sales';
Disabled.

DISABLE FAST_START FAILOVER

Disables fast-start failover and prevents the observer from initiating a failover to the target standby database. See Section 5.5.4, "Disabling Fast-Start Failover" for complete information.

Format

DISABLE FAST_START FAILOVER [ FORCE ];

Command Parameters

None.

Usage Notes

- If the primary and target standby database have a network connection, use DISABLE FAST_START FAILOVER without the FORCE option to disable fast-start failover on all databases in the broker configuration. If errors occur during the disable operation, the broker returns an error message and stops the disable operation. You may need to reissue the DISABLE FAST_START FAILOVER command with the FORCE option to override the error conditions and disable fast-start failover.

- Use DISABLE FAST_START FAILOVER with the FORCE option when the network between the primary and target standby databases is disconnected or when the database upon which the command is received does not have a connection with the primary database. The FORCE option disables fast-start failover on the database to which you are connected, even when errors occur.

- Disabling fast-start failover with the FORCE option on a primary database that is disconnected from the observer and the target standby database does not prevent the observer from initiating a fast-start failover to the target standby database.

- You can disable fast-start failover while connected to any database in the broker configuration.

- If disabled by force at the target standby database and the connection subsequently resumes with the primary database, fast-start failover is disabled on all databases in the configuration.

Command Example

Example 1

The following example shows how to disable fast-start failover.

DGMGRL> DISABLE FAST_START FAILOVER;
Disabled.

EDIT CONFIGURATION (Property)

Changes the value of a property for the broker configuration.

Format

EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = threshold-seconds;

Command Parameter

property-name

The FastStartFailoverThreshold property

Usage Notes

- Issue this command while connected to the primary database or to any standby database in the broker configuration having connectivity to the primary database.

- This command specifies a value for the FastStartFailoverThreshold property. The number of seconds you specify determines how long the observer and target standby database should simultaneously wait to hear from the primary database before initiating a fast-start failover. The FastStartFailoverThreshold property is discussed in Section 9.2.10 and in Section 5.5.2.

- Set this property to increase or decrease the sensitivity of the fast-start failover trigger.

- Specify the threshold-value as a positive, nonzero number of seconds. The default value is 30 seconds and may be made to be configuration-dependent (for example, if the primary database is a RAC.)

- This property may be modified whether fast-start failover is enabled or disabled.

- Use the SHOW CONFIGURATION command to display the current property information for the configuration.

Command Example

Example 1

The following example shows how to set the FastStartFailoverThreshold property to 90 seconds.

DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThresdhold=90;

EDIT CONFIGURATION (Protection Mode)

Edits the current protection mode setting for the broker configuration.

Format

EDIT CONFIGURATION SET PROTECTION MODE AS protection-mode;

Command Parameter

protection-mode

The data protection mode in which you want the configuration to run when the configuration is enabled. The possible protection modes are:

MAXPROTECTION
MAXAVAILABILITY
MAXPERFORMANCE

Usage Notes

- Before you use the EDIT CONFIGURATION command to set the protection mode to either the MAXPROTECTION or MAXAVAILABILITY mode, ensure that standby redo log files are configured on a standby database.

- The following table shows the configuration protection modes and the minimum corresponding settings for redo transport services:

Protection Mode

Redo Transport

Standby Redo Log Files Needed?

Required for Fast-Start Failover?

MAXPROTECTION

SYNC

Yes

No

MAXAVAILABILITY

SYNC

Yes

Yes

MAXPERFORMANCE

ARCH or ASYNC

Yes for ASYNC

No

The default protection mode for the configuration is MAXPERFORMANCE.

See Also:
Chapter 4 for more information about the protection modes and redo transport services

- MAXAVAILABILITY is required in order to enable fast-start failover.

- This command cannot be executed if fast-start failover is enabled.

- After you change the protection mode, the broker will automatically restart the primary database, if necessary.

- Use the SHOW CONFIGURATION command to display the current protection mode for the configuration.

DGMGRL> SHOW CONFIGURATION;

Configuration
Name:            DRSolution
Enabled:         YES
Protection Mode: MaxPerformance
Databases:
North_Sales - Primary database
DR_Sales    - Physical standby database

Current status for "DRSolution":
SUCCESS

If broker management of the configuration is disabled when you enter the EDIT CONFIGURATION command, the protection mode of the configuration does not take effect until the next time you enable the configuration with the ENABLE CONFIGURATION command.

Command Example

Example 1

The following example shows how to upgrade the broker configuration to the MAXPROTECTION protection mode. The broker configuration will have the maximum amount of data protection after these commands complete.

Verify that standby redo log files are configured on the standby database and that the redo transport service is set to SYNC, for example:

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC';
Property "LogXptMode" updated

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION;
Operation requires shutdown of instance "sales1" on database "North_Sales"
Shutting down instance "sales1"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "sales1" on database "North_Sales"
Starting instance "sales1"...
ORACLE instance started.
Database mounted.

The broker automatically stops and restarts the primary database.

EDIT DATABASE (Property)

Changes the value of a property for the named database.

Format

EDIT DATABASE database-name

SET PROPERTY property-name = value;

Command Parameters

database-name

The name of the database for which you want to change a property value.

property-name

The name of an existing database-specific property. If this is a RAC database, this property change affects all instances of the database.

See Also:
Chapter 4 and Chapter 9 for information about properties.

value

The new value for the property.

Caution:
This command can be used to change the value of a per-instance property if and only if just one instance is known by the broker for the named database. An attempt to use this command to change a per-instance property when the broker knows of multiple instances of the database will be rejected. It is recommended to only use EDIT INSTANCE (property) to change the value of a per-instance property.

Command Examples

Example 1

Edit a database level property.

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'ArchiveLagTarget'=1200;
Property "ArchiveLagTarget" updated

Example 2

Edit an instance level property of a non-RAC database.

DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY
> 'StandbyArchiveLocation'='/archfs/arch/';
Property "StandbyArchiveLocation" updated

Example 3

Edit an instance level property of a RAC database. This will not succeed because it is not clear to which instance the property change should be applied.

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY
> 'StandbyArchiveLocation'='/archfs/arch/';
Error: ORA-16587: ambiguous object specified to Data Guard broker

Failed.

EDIT DATABASE (Rename)

Changes the name used by the broker to refer to the specified database, as recorded in that database's profile in the broker configuration.

Format

EDIT DATABASE database-name

RENAME TO new-database-name;

Command Parameters

database-name

The name of the database that you want to change.

new-database-name

The name of the new database.

Usage Notes

- Use this command to track changes to the DB_UNIQUE_NAME initialization parameter for this database.

Caution:

The database-name must always match the value for that database's DB_UNIQUE_NAME initialization parameter.

- This command can only be done when broker management of the database that you are renaming is disabled.

Command Example

Example 1

The following example shows how to edit and rename a database.

DGMGRL> EDIT DATABASE 'DR_Sales_typo' RENAME TO 'DR_Sales';
Succeeded.

DGMGRL> ENABLE DATABASE 'DR_Sales';
Enabled.

EDIT DATABASE (State)

Changes the state of the specified database.

Format

EDIT DATABASE database-name

SET STATE = state

[WITH APPLY INSTANCE = instance-name];

Command Parameters

database-name

The name of the database for which you want to change the state.

state

The state in which you want the database to be running. The possible states are:

ONLINE
LOG-TRANSPORT-OFF (primary database only)
LOG-APPLY-OFF (standby database only)
READ-ONLY (physical standby database only)
OFFLINE

instance-name

The name of the instance you want to become the apply instance if this is a RAC standby database.

Usage Notes

- If the target state is ONLINE and this database is currently in the standby role, the optional WITH APPLY INSTANCE clause specifies which instance will become the apply instance.

- If the target state is not ONLINE or if the database is currently in the primary role, the WITH APPLY INSTANCE clause is ignored even if it is specified.

- All instances of a RAC database are affected by this database state change.

Command Example

The following examples show how to change the state of a database.

Example 1

DGMGRL> EDIT DATABASE 'DR_Sales' SET STATE='READ-ONLY';
Succeeded.

Example 2

DGMGRL> EDIT DATABASE 'North_Sales' SET STATE='OFFLINE';
Operation requires shutdown of instance "sales1" on database "North_Sales"
Shutting down instance "sales1"...
Database closed.
Database dismounted.
ORACLE instance shut down.

EDIT INSTANCE (AUTO PFILE)

Sets the name of the initialization parameter file for the specified instance.

Format

EDIT INSTANCE instance-name

[ON DATABASE database-name]

SET AUTO PFILE [= { initialization-file | OFF } ];

Command Parameters

instance-name

The name of the instance (SID) for which you want to specify its initialization parameter file.

database-name

The name of the database to which the instance-name is associated.

initialization-file

Executes the startup operation for the instance when a subsequent broker operation requires the instance to be started automatically. If SET AUTO PFILE is set to OFF, automatic restart of that instance is disabled. When a subsequent operation needs to start that instance, you must start it manually. If you do not specify SET AUTO PFILE for the instance, the automatic startup operation looks for the initialization parameter file at the default location.

Usage Notes

- The instance-name can be unique across the configuration. If instance-name is not unique, you must specify both the database-name and the instance-name to fully identify the instance.

- SET AUTO PFILE is valid only for the duration of the current DGMGRL session. You must specify SET AUTO PFILE again if you quit and reenter DGMGRL.

Command Example

Example 1

The following example shows how to edit an instance of a database.

DGMGRL> EDIT INSTANCE 'dr_sales1' ON DATABASE 'DR_Sales'
> SET AUTO PFILE='initsales1.ora';
Instance 'dr_sales1' updated

EDIT INSTANCE (Property)

Changes the value of a property for the specified instance.

Format

EDIT INSTANCE instance-name

[ON DATABASE database-name]

SET PROPERTY property-name = value;

Command Parameters

instance-name

The name of the instance (SID) for which you want to change a per-instance property value.

database-name

The name of the database to which the instance-name is associated.

property-name

The name of the per-instance property for which you want to set a new value.

See Also:
Chapter 4 and Chapter 9 for information about properties.

value

The new value for the property.

Usage Notes

- The instance-name can be unique across the configuration. If instance-name is not unique, you must specify both the database-name and the instance-name to fully identify the instance.

- This command cannot be used to change a database-specific property.

Command Examples

Example 1

Edit an instance level property.

DGMGRL> EDIT INSTANCE 'sales1' ON DATABASE 'North_Sales'
> SET PROPERTY 'StandbyArchiveLocation'='/archfs/arch/';
Property "StandbyArchiveLocation" updated.

Example 2

Edit a database level property. This will not be allowed.

DGMGRL> EDIT INSTANCE 'sales1' ON DATABASE 'North_Sales'
> SET PROPERTY 'LogXptMode'='SYNC';
Error: ORA-16586: could not edit database property through instance

Failed.

ENABLE CONFIGURATION

Enables the broker to actively manage the broker configuration including all of its databases.

Format

ENABLE CONFIGURATION;

Command Parameters

None.

Usage Notes

- Use this command to enable broker management of the primary database.

- By default, broker management of the configuration's databases is enabled in the ONLINE state with redo transport services turned on at the primary database and log apply services turned on at the standby databases. You can change the state of any database using the EDIT DATABASE (State) command, but not when the database or the entire configuration is disabled.

- Use the SHOW CONFIGURATION command to display information about the configuration.

Command Example

Example 1

The following example enables management of a broker configuration.

DGMGRL> ENABLE CONFIGURATION;
Enabled.

ENABLE DATABASE

Enables broker management of the specified standby database.

Caution:
Do not issue the ENABLE DATABASE command on a standby database that needs to be reinstated. See Section 5.4.3 for more details.

Format

ENABLE DATABASE database-name;

Command Parameter

database-name

The name of the standby database for which you want to enable broker management.

Usage Notes

- A standby database may have been disabled by the broker as a consequence of a prior failover or switchover operation. See Section 5.4.3 to understand how the database can be reenabled.

- By default, broker management of the standby database is enabled in the ONLINE state with log apply services enabled. You can change the state of the standby database using the EDIT DATABASE (State) command, but only when the database is enabled.

- Use the SHOW DATABASE command to display information about the database.

- For a RAC database, only one instance is required to be started and mounted for this command to succeed.

Command Example

Example 1

The following example shows how to enable a database named DR_Sales.

DGMGRL> ENABLE DATABASE 'DR_Sales';
Enabled.

ENABLE FAST_START FAILOVER

Enables the broker to fail over to a specifically-chosen, synchronized standby database in the event of loss of the primary database, without requiring you to perform any manual steps to invoke the failover. See Section 5.5.2, "Enabling Fast-Start Failover" for complete information.

Format

ENABLE FAST_START FAILOVER;

Command Parameters

None.

Usage Notes

- The prerequisites described in Section 5.5.1 must be met before you issue this command to enable fast-start failover.

- Issuing the ENABLE FAST_START FAILOVER command does not trigger a failover, it only allows the observer to monitor the configuration and initiate fast-start failover if conditions warrant a failover.

- You can enable fast-start failover while connected to any database system in the broker configuration.

- If you do not start the observer after you have enabled fast-start failover, the ORA-16819 warning displays for the primary and target standby databases. For example:

DGMGRL> SHOW DATABASE 'North_Sales';
Database
Name:            North_Sales
Role:            PRIMARY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
sales1

Current status for "North_Sales":
Warning: ORA-16819: Fast-Start Failover observer not started

- To enable fast-start failover for a broker configuration with multiple standby databases, the FastStartFailoverTarget property on the primary database and one standby database must be set to point to each other. Both the primary database and the target standby database must have:

- Standby redo logs configured

- The LogXptMode property set to SYNC

- Flashback Database enabled on both the primary and standby databases

In addition, the configuration protection mode must be set to MAXAVAILABILITY. Step 2 in Section 5.5.2 and Section 9.2.9 provide more information about the FastStartFailoverTarget property.

- Once you have enabled fast-start failover, you must comply with the restrictions described in Section 5.5.2.2, "Restrictions When Fast-Start Failover is Enabled".

Command Example

Example 1

The following example enables fast-start failover.

DGMGRL> ENABLE FAST_START FAILOVER;
Enabled.

Example 2

The following example attempts to enable fast-start failover when the configuration protection mode is MAXPERFORMANCE.

DGMGRL> SHOW CONFIGURATION;

Configuration
Name:                The SUPER cluster
Enabled:             YES
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
dgb1  - Primary database
dgb12 - Physical standby database

Current status for "The SUPER cluster":
SUCCESS

DGMGRL> ENABLE FAST_START FAILOVER;
Error: ORA-16651: requirements not met for enabling Fast-Start Failover

Failed.

EXIT

Exits (quits) the command-line interface.

Format

EXIT;

Command Parameters

None.

Usage Notes

- This command has the same effect as the QUIT command.

- A database connection is not required to execute this command. However, if you are connected, this command breaks the connection.

Command Example

Example 1

The following example demonstrates how to exit (quit) the command-line interface.

DGMGRL> EXIT;

FAILOVER

Invokes a failover that transitions the named (target) standby database into the role of a primary database. This type of failover is referred to as manual failover. See Section 5.4, "Manual Failover" for more information.

Note:
Because a failover results in a transition of a standby database to the primary role, it should be performed only in the event of a catastrophic failure of the primary database when there is no possibility of recovering the primary database in a timely manner. Failover may or may not result in data loss depending on the protection mode in effect at the time of the failover and whether the target standby database was synchronized with the primary database.
Use the SWITCHOVER command if you want the current primary database and a standby database to switch roles with no data loss.

Format

FAILOVER TO database-name

[ IMMEDIATE ];

Command Parameters

database-name

The name of the standby database you want to fail over to the primary database role.

Usage Notes

- You can perform a manual failover or set up the broker to perform a fast-start failover. See the ENABLE FAST_START FAILOVER command for information about allowing the broker to automatically invoke failover, when conditions warrant a failover.

- If fast-start failover is enabled, you may perform a complete manual failover only to the target standby database and only if the target standby database is synchronized with the primary database, and only when the observer is started. You cannot perform an immediate manual failover when fast-start failover is enabled.

- The specified standby database must be enabled before the primary database fails. However, an enabled standby database that was taken offline can be a candidate for the failover operation. In this case, restart the standby database using DGMGRL STARTUP command, then issue the FAILOVER command.

- The failover operates on the specified standby database and changes one its role to a primary database. Any other standby databases not involved in the failover remain in the standby role.

- Before you issue the FAILOVER command, verify that you are connected to the standby database that will become the new primary database. If necessary, issue a CONNECT command to connect to the standby database.

- If the FAILOVER command is issued without any options, the standby database chosen as the failover target applies all unpiled redo it has received before changing to the primary role.

- If the standby database that you want to fail over to the primary role is a RAC database, the broker will shut down all of the instances except the apply instance before it continues the failover operation. See Section 5.4.3 for details.

- If the standby database that is transitioning into the role of primary database is a physical standby database, then the database instance (or instances) will be restarted if the database was opened read-only prior to the failover. The database restart occurs as part of the failover. If the database is a logical standby database, the database instance (or instances) does not need to be restarted. Failing over to a logical standby database has the side effect of disabling all other standby databases in the configuration.

- If the broker configuration is in either MAXPROTECTION or MAXAVAILABILITY protection mode, a manual failover operation will force the protection mode to be MAXPERFORMANCE. The redo transport service settings are unaffected. You need to restore the desired protection mode for the resulting configuration after the failover operation.

Note:
With fast-start failover, the broker preserves the protection mode at the same maximum availability level in which it was operating before the failover.

- If the FAILOVER command is issued with the IMMEDIATE option, no attempt is made to apply any unapplied redo that has been received. This option more likely results in lost application data even when standby redo log files are configured on the standby database. Additionally, any remaining standby databases in the configuration cannot function as such until they are reenabled. See Section 5.4.3 for more information about reenabling databases.

- If Flashback Database was enabled on the former (failed) primary database prior to the failover, the former primary database can be reinstated using the broker's REINSTATE command (see the REINSTATE DATABASE command).

If failover was performed to a physical standby database, any other physical standby databases that were disabled by the failover can be reinstated if Flashback Database was enabled on the standby database and there are sufficient flashback logs available. See Section 5.4.3, "Reenabling Disabled Databases After Failover or Switchover" for step-by-step instructions.

- The original primary database can only participate in the configuration as a standby database after it is reenabled.

Caution:
You should shut down the original primary database if it still has any active instances running prior to failing over.

See Also:
Section 5.4.3 about reenabling the original primary database so that it could serve as a standby database to the primary database

Command Examples

Example 1

The following example performs a failover in which the standby database, DR_Sales, transitions to the primary role:

DGMGRL> FAILOVER TO "DR_Sales";
Performing failover NOW, please wait...
Operation requires shutdown of instance "dr_sales1" on database "DR_Sales"

Shutting down instance "dr_sales1"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "dr_sales1" on database "DR_Sales"
Starting instance "dr_sales1"...
ORACLE instance started.
Database mounted.
Failover succeeded, new primary is "DR_Sales"

HELP

Displays online help for the Data Guard command-line interface.

Format

HELP [topic];

Command Parameter

topic

The topic for which you want to display help information. If you do not specify a topic, the command lists all of the topics and the format. Valid topics are:

ADD
CONNECT
CREATE
DISABLE
EDIT
ENABLE
EXIT
FAILOVER
HELP
QUIT
REINSTATE
REM
REMOVE
SHOW
SHUTDOWN
START
STARTUP
STOP
SWITCHOVER

Usage Note

- A database connection is not required to execute this command.

Command Examples

Example 1

The following examples get help on the HELP and CONNECT commands.

DGMGRL> HELP HELP;

Display description and syntax for a given command

Syntax:

HELP [<command>];

DGMGRL> HELP CONNECT;

Connect to an Oracle instance

Syntax:

CONNECT <username>/<password>[@<connect identifier>]

Example 2

The following example gets help on the EDIT commands.

DGMGRL> HELP EDIT

Edit a configuration, database or instance

Syntax:

EDIT CONFIGURATION SET PROTECTION MODE AS
{MaxProtection|MaxAvailability|MaxPerformance};
EDIT CONFIGURATION SET PROPERTY <property name> = <value>;

EDIT DATABASE <database name> SET PROPERTY <property name> = <value>;

EDIT DATABASE <database name> RENAME TO <new database name>;

EDIT DATABASE <database name> SET STATE = <state>
[WITH APPLY INSTANCE = <instance name>];

EDIT INSTANCE <instance name> [ON DATABASE <database name>]
SET AUTO PFILE [ = {<initialization file path>|OFF} ];

EDIT INSTANCE <instance name> [ON DATABASE <database name>]
SET PROPERTY <property name> = <value>;

QUIT

Quits (exits) the Data Guard command-line interface.

Format

QUIT;

Command Parameters

None.

Usage Notes

- This command has the same effect as the EXIT command.

- A database connection is not required to execute this command. However, if you are connected, this command breaks the connection.

Command Example

Example 1

The following example shows how to quit (exit) the command-line interface.

DGMGRL> QUIT;

REINSTATE DATABASE

Reinstates a former primary database as a new standby database in the broker configuration for the current primary database.

Format

REINSTATE DATABASE database-name;

Command Parameter

database-name

The name of the database that is to be reinstated in the broker configuration.

Usage Notes

- If the conditions for reinstatement described in Section 5.5.7 are not satisfied, the reinstatement will fail with an appropriate error status and the specified database will remain disabled.

- If the database-name specified is that of the old primary and fast-start failover is enabled, the old primary database will be reinstated as a standby to the new primary, and the fast-start failover environment will be updated to reflect the availability of the new standby database. It will accept redo data from the new primary database and be the target of a fast-start failover should the new primary database fail. Reinstatement occurs automatically if the observer is running.

- This command does not require that fast-start failover is enabled. It can be used to reinstate an old primary database after a complete manual failover has been performed.

- Issue this command while connected to any database in the broker configuration, except the database that is to be reinstated.

Command Examples

Example 1

The following example reinstates the DR_Sales database as a standby database in the broker configuration.

DGMGRL> REINSTATE DATABASE 'North_Sales';
Reinstating database "North_Sales", please wait...
Operation requires shutdown of instance "sales1" on database "North_Sales"
Shutting down instance "sales1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "sales1" on database "North_Sales"
Starting instance "sales1"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "North_Sales" ...
Reinstatement of database "North_Sales" succeeded

REMOVE CONFIGURATION

Removes all of the broker configuration information, including all database profiles, from the Data Guard configuration file, and terminates broker management of all of the databases associated with the broker configuration.

Caution:
When you use the REMOVE CONFIGURATION command, all profile information is deleted from the Data Guard configuration file and cannot be recovered.

Format

REMOVE CONFIGURATION [ PRESERVE DESTINATIONS ];

Command Parameters

None.

Usage Notes

- When you remove a broker configuration, management of all of the databases associated with that configuration is disabled.

- By default, the command removes the corresponding broker settings of the LOG_ARCHIVE_DEST_n initialization parameter on the primary database and the LOG_ARCHIVE_CONFIG initialization parameters on all databases in the configuration. To preserve these settings, use the PRESERVE DESTINATIONS option.

- This command does not remove or affect the actual primary or standby database instances, databases, datafiles, control files, initialization parameter files, server parameter files, or log files of the underlying Data Guard configuration.

- You cannot remove the configuration when fast-start failover is enabled.

Command Example

The following examples show a successful and an unsuccessful REMOVE CONFIGURATION command.

Example 1   Successful REMOVE CONFIGURATION Command

The following command shows how to remove configuration information from the configuration file.

DGMGRL> REMOVE CONFIGURATION;
Removed configuration
DGMGRL> SHOW CONFIGURATION;
Error: ORA-16532: Data Guard broker configuration does not exist

Configuration details cannot be determined by DGMGRL

Example 2   Unsuccessful REMOVE CONFIGURATION Command

The following command is unsuccessful because fast-start failover is enabled.

DGMGRL> REMOVE CONFIGURATION;
Error: ORA-16654: Fast-Start Failover was enabled

Failed.
DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxAvailability
Fast-Start Failover: ENABLED
Databases:
North_Sales  - Primary database
West_Sales   - Logical standby database
- Fast-Start Failover target
DR_Sales     - Physical standby database

Fast-Start Failover
Threshold: 45 seconds
Observer:  stacm29

Current status for "DRSolution":
SUCCESS

REMOVE DATABASE

Removes the specified standby database's profile from the broker configuration and terminates broker management of the standby database.

Caution:
When you use the REMOVE DATABASE command, the database's profile information is deleted from the broker configuration file and cannot be recovered.

Format

REMOVE DATABASE database-name [ PRESERVE DESTINATIONS ];

Command Parameter

database-name

The name of the standby database whose profile you want to remove from the broker configuration.

Usage Note

- An error is returned if you specify the name of the primary database in the broker configuration.

- By default, the command removed the corresponding broker settings of the LOG_ARCHIVE_DEST_n initialization parameter on the primary database and the LOG_ARCHIVE_CONFIG initialization parameter on all databases in the configuration. To preserve these settings, use the PRESERVE DESTINATIONS option.

- This command cannot be executed if fast-start failover is enabled and database-name specifies the name of the target standby database.

Command Example

Example 1

The following example shows how to remove a database from the Data Guard configuration.

DGMGRL> SHOW CONFIGURATION;

Configuration
Name:                DRSolution
Enabled:             NO
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database
DR_Sales     - Physical standby database

Current status for "DRSolution":
SUCCESS

DGMGRL> REMOVE DATABASE 'DR_Sales';
Removed database "DR_Sales" from the configuration

DGMGRL> SHOW CONFIGURATION;
Configuration
Name:                DRSolution
Enabled:             NO
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database

Current status for "DRSolution":
SUCCESS

REMOVE INSTANCE

Removes an instance from an existing database profile in the broker configuration.

Format

REMOVE INSTANCE instance-name

[ON DATABASE database-name];

Command Parameters

instance-name

The name of the instance (SID) that you want to remove from the broker configuration.

database-name

The name of the database to which the instance-name is associated.

Usage Notes

- In a RAC database, the broker automatically adds started instances into the corresponding database profile. However, the broker may not automatically remove instances from the database profile. The REMOVE INSTANCE command can be used to manually remove any instance that no longer exists from the database profile.

- The instance-name can be unique across the configuration. If instance-name is not unique, you must specify both the database-name and the instance-name to fully identify the instance.

- This command is rejected for an instance that is currently active in the broker configuration.

- This command is rejected if this is the only instance currently associated with a database profile.

Command Example

Example 1

The following example shows how to remove an instance of the database.

DGMGRL> REMOVE INSTANCE 'dr_sales3' ON DATABASE 'DR_Sales';
Removed instance "dr_sales3" from the database "DR_Sales"

SHOW CONFIGURATION

Displays a summary and status of the broker configuration. The summary lists all databases included in the broker configuration and other information pertaining to the broker configuration itself, including the fast-start failover status.

Format

SHOW CONFIGURATION [VERBOSE];

Command Parameters

None.

Usage Notes

- Use SHOW CONFIGURATION VERBOSE to show the fast-start failover threshold and the observer host system when fast-start failover is enabled.

Command Examples

Example 1   Showing a Summary of the DRSolution Configuration

The following example provides a summary of the DRSolution configuration.

DGMGRL> SHOW CONFIGURATION;

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxPerformance
Fast-Start Failover: DISABLED
Databases:
North_Sales  - Primary database
DR_Sales     - Physical standby database

Current status for "DRSolution"
SUCCESS

Example 2   Verifying the Readiness of Fast-Start Failover

The following example verifies the readiness of the fast-start failover configuration:

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxAvailability
Fast-Start Failover: ENABLED
Databases:
North_Sales - Primary database
DR_Sales    - Physical standby database
- Fast-Start Failover target
Fast-Start Failover
Threshold: 45 seconds
Observer:  observer.foo.com
Current status for "DRSolution":
SUCCESS

SHOW DATABASE

Displays information or property values of the specified database and its instances.

Format

SHOW DATABASE [VERBOSE] database-name [property-name];

Command Parameters

database-name

The name of the database for which you want to display information.

property-name

The name of the property for which you want to display a value.

See Also:
Chapter 4 and Chapter 9 for information about properties.

Usage Notes

- The SHOW DATABASE command shows a brief summary of the database. SHOW DATABASE VERBOSE shows properties of the database in addition to the brief summary. They both show the status of the database.

- The SHOW DATABASE VERBOSE command shows database-specific properties and instance-specific properties. For a non-RAC database, the values of the instance-specific properties are those of the only instance of the database. For a RAC database, the values of the instance-specific properties will not be shown, although the property names are still listed. To see the instance-specific values of these properties, use the SHOW INSTANCE command.

- The properties that the SHOW DATABASE VERBOSE command shows depend on the database role and the configuration composition:

- For the primary database, properties specific to physical standby databases are shown only if there is at least one physical standby database in the configuration. The properties specific to logical standby databases are shown only if there is at least one logical standby database in the configuration.

- For physical standby databases, properties specific to logical standby databases are not shown.

- For logical standby databases, properties specific to physical standby databases are not shown.

- This command is rejected if you use SHOW DATABASE property-name command to show an instance-specific property in a RAC database.

Command Examples

Example 1

Shows database information in an abbreviated format.

DGMGRL> SHOW DATABASE 'DR_Sales';
Database
Name:            DR_Sales
Role:            PHYSICAL STANDBY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
dr_sales1

Current status for "DR_Sales":
SUCCESS

Example 2

Shows database information in an extended format.

DGMGRL> SHOW DATABASE VERBOSE 'North_Sales'
Database
Name:            North_Sales
Role:            PRIMARY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
sales1
Properties:
InitialConnectIdentifier        = 'North_Sales.foo.com'
LogXptMode                      = 'ARCH'
Dependency                      = ''
DelayMins                       = '0'
Binding                         = 'OPTIONAL'
MaxFailure                      = '0'
MaxConnections                  = '0'
ReopenSecs                      = '30'
NetTimeout                      = '180'
LogShipping                     = 'ON'
PreferredApplyInstance          = ''
ApplyInstanceTimeout            = '0'
ApplyParallel                   = 'AUTO'
StandbyFileManagement           = 'AUTO'
ArchiveLagTarget                = '0'
LogArchiveMaxProcesses          = '5'
LogArchiveMinSucceedDest        = '1'
DbFileNameConvert               = 'dbs/s2t, dbs/t'
LogFileNameConvert              = 'dbs/s2t, dbs/t'
FastStartFailoverTarget         = ''
StatusReport                    = '(monitor)'
InconsistentProperties          = '(monitor)'
InconsistentLogXptProps         = '(monitor)'
SendQEntries                    = '(monitor)'
LogXptStatus                    = '(monitor)'
RecvQEntries                    = '(monitor)'
HostName                        = 'north.foo.com'
SidName                         = 'sales1'
LocalListenerAddress            = '(ADDRESS=(PROTOCOL=TCP)(HOST=north.foo.com)(PORT=1514))'
StandbyArchiveLocation          = '/archfs/arch/'
AlternateLocation               = ''
LogArchiveTrace                 = '255'
LogArchiveFormat                = 'r_%d_%t_%s_%r.arc'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'
Current status for "North_Sales":
SUCCESS

SHOW INSTANCE

Displays information or property value of the specified instance.

Format

SHOW INSTANCE [VERBOSE] instance-name [property-name]

[ON DATABASE database-name];

Command Parameters

instance-name

The name of the instance for which you want to display information.

property-name

The name of the property for which you want to display a value.

See Also:
Chapter 4 and Chapter 9 for information about properties.

database-name

The name of the database to which is associated the instance for which you want to show information.

Usage Notes

- The SHOW INSTANCE command shows a brief summary of the instance. SHOW INSTANCE VERBOSE shows properties of the instance in addition to the brief summary. They both show the status of the instance.

- The SHOW INSTANCE VERBOSE command only shows instance-specific properties.

- The properties that the SHOW INSTANCE VERBOSE command shows depend on the database role and the configuration composition:

- For instances of the primary database, properties specific to physical standby instances are shown only if there is at least one physical standby database in the configuration. The properties specific to logical standby instances are shown only if there is at least one logical standby database in the configuration.

- For instances of physical standby databases, properties specific to logical standby instances are not shown.

- For instances of logical standby databases, properties specific to physical standby instances are not shown.

- The instance-name can be unique across the configuration. If instance-name is not unique, you must specify both the database-name and the instance-name to fully identify the instance.

Command Example

Example 1

The following example shows information about a specific instance of a database.

DGMGRL> SHOW INSTANCE sales1;

Instance 'sales1' of database 'North_Sales'
Host Name:       north.foo.com

Current status for "sales1":
SUCCESS

Example 2

Shows instance information in an extended format.

DGMGRL> SHOW INSTANCE VERBOSE sales1;

Instance 'sales1' of database 'North_Sales'
Host Name:       north.foo.com
PFILE:

Properties:
HostName                        = 'north.foo.com'
SidName                         = 'sales1'
LocalListenerAddress            = '(ADDRESS=(PROTOCOL=TCP)(HOST=north.foo.com)(PORT=1514))'
StandbyArchiveLocation          = '/archfs/arch'
AlternateLocation               = ''
LogArchiveTrace                 = '255'
LogArchiveFormat                = 'r_%d_%t_%s_%r.arc'
LsbyMaxSga                      = '0'
LsbyMaxServers                  = '0'
LatestLog                       = '(monitor)'
TopWaitEvents                   = '(monitor)'

Current status for "sales1":
SUCCESS

SHUTDOWN

Shuts down a currently running Oracle instance.

Format

SHUTDOWN [ ABORT | IMMEDIATE | NORMAL ];

Command Parameters

None.

Usage Notes

- Using the SHUTDOWN command with no arguments is equivalent to using the SHUTDOWN NORMAL command.

- The following list describes the options to the SHUTDOWN command:

- ABORT

Proceeds with the fastest possible shutdown of the database without waiting for calls to complete or for users to disconnect from the database. Uncommitted transactions are not rolled back. Client SQL statements being processed are terminated. All users connected to the database are implicitly disconnected, and the next database startup will require instance recovery. You must use this option if a background process terminates abnormally.

Caution:
If you use the ABORT option on the primary database when fast-start failover is enabled and the observer is running, a fast-start failover may ensue. Use the IMMEDIATE or NORMAL option to prevent an unexpected fast-start failover from occurring.

- IMMEDIATE

Does not wait for current calls to complete or users to disconnect from the database. Further connections are prohibited. The database is closed and dismounted. The instance is shut down, and no instance recovery is required on the next database startup.

- NORMAL

This is the default option. The process waits for users to disconnect from the database. Further connections are prohibited. The database is closed and dismounted. The instance is shut down, and no instance recovery is required on the next database startup.

Command Example

Example 1

The following command shuts down the primary database in normal mode.

DGMGRL > SHUTDOWN;

Database closed.
Database dismounted.
Oracle instance shut down.

START OBSERVER

Starts the fast-start failover observer.

Format

START OBSERVER [ FILE=observer_configuration_filename ];

Command Parameters

filename

Specifies an explicit directory path and file name on the observer computer.

Usage Notes

- The Oracle Client Administrator kit, or the full Oracle Database Enterprise Edition or Oracle Personal Edition kit must be installed on the observer computer to monitor a broker configuration for which fast-start failover is to be enabled. See Section 5.5.1 for more information.

- The START OBSERVER command must be issued on the observer computer. Once the observer is successfully started, control is not returned to the user until the observer is stopped (for example, by issuing the STOP OBSERVER command from a different client connection). If you want to perform further interaction with the broker configuration, you must connect through another client.

- The observer runs autonomously once it has been successfully started. For this reason, it is recommended that when invoking DGMGRL for the purpose of issing the START OBSERVER command, specify the -logfile optional parameter on the command line so that output generated while acting as the observer is not lost. See Section 8.1.1 for more information about this parameter and see Section 10.5.3 for an example use of the -logfile option.

- If a directory path is not specified with the FILE parameter, the observer searches the current working directory for the fsfo.dat file. If an fsfo.dat file is not found and this is the first time the START OBSERVER command is issued, the observer creates a fsfo.dat file.

- The primary and target standby database DB_UNIQUE_NAME initialization parameter and connect descriptors are stored in the fsfo.dat configuration file. Oracle recommends you ensure this file is protected from unauthorized access.

- Fast-start failover does not need to be enabled before you issue this command.

- If fast-start failover is enabled, the observer will retrieve primary and target standby connect descriptors from the broker configuration and begin monitoring the configuration.

- If fast-start failover is not enabled, the observer continually monitors for when fast-start failover is enabled.

- Only the primary database needs to be running when you issue this command; the standby database that will be the target of a fast-start failover does not need to be running.

- If the observer is stopped:

- Because the STOP OBSERVER command was issued, you can issue the START OBSERVER command on any computer to restart the observer.

- For any reason other than because the STOP OBSERVER command was issued, you must issue the START OBSERVER command on the same observer computer where it was started originally.

- If an observer is already running, the START OBSERVER command fails and returns one of the following errors:

ORA-16647: could not start more than one observerDGM-16954: unable to open and lock the Observer configuration file.

- If the primary and target standby databases stay connected but they lose the connection to the observer, then the primary database goes into an unobserved state. This state is reported by the broker's health check capability.

- Use the SHOW CONFIGURATION VERBOSE command, or query the FS_FAILOVER_* columns in the V$DATABASE view on the primary database to see the status of the observer and its host computer.

Command Examples

Example 1

The following example shows...

DGMGRL> CONNECT sys/password@North_Sales.foo.com;
DGMGRL> START OBSERVER;
Observer started

Example 2

The following example shows how to start the observer using CONNECT '/' so that connection credentials are not visible on the command line:

DGMGRL> CONNECT /@North_Sales.foo.com;
DGMGRL> START OBSERVER;
Observer started.

You must set up Oracle Wallet to use CONNECT '/'. By setting up Oracle Wallet, you can write a script to securely start and run the observer as a background job without specifying database credentials in the script.

See Also:
Oracle Database Advanced Security Administrator's Guide for more information about Oracle Wallet

STARTUP

Starts an Oracle database instance with any of the following options:

- FORCE: shuts down the current Oracle instance in the SHUTDOWN ABORT mode before restarting it.

- RESTRICT: allows only Oracle users with the RESTRICTED SESSION system privilege to connect to the instance.

- PFILE: specifies the PFILE initialization parameter file to be used when the database instance is started.

- MOUNT: mounts the specified database without opening it. However, if the broker is enabled (DG_BROKER_START=TRUE) and the specified database is a primary database or a logical standby database, the broker will attempt to open the database if the database profile indicates the database should be opened.

- OPEN: mounts and opens the specified database.

- NOMOUNT: starts the specified database instance without mounting the database.

Format

STARTUP

[FORCE]

[RESTRICT]

[PFILE=filename]

[MOUNT] | OPEN [open-options] | NOMOUNT];

Command Parameters

filename

The name of the initialization parameter file to be used when starting the database instance. If you do not specify the PFILE parameter option, then the default server parameter file (specific to your operating system) is used.

open-options

The mode of access in which you want the specified database to start. The possible modes are:

READ ONLY
READ WRITE

Usage Notes

- Using the STARTUP command with no arguments is equivalent to using the STARTUP OPEN command.

- If you do not use the FORCE clause when you use the STARTUP command and the current database instance is running, an error results. The FORCE clause is useful when you are debugging or when error conditions are occurring. Otherwise, it should not be used.

- Use the RESTRICT clause to allow only Oracle users with the RESTRICTED SESSION system privilege to connect to the instance. Later, you can use the ALTER SYSTEM command through SQL*Plus to disable the restricted session feature.

- If you do not use the PFILE clause to specify the initialization parameter file, the STARTUP command uses the default server parameter file, if it exists. Otherwise, the STARTUP command uses the default initialization parameter file. The default files are platform specific.

See your operating system-specific documentation for more information about the default parameter files.

- Use the OPEN clause to mount and open the specified database.

- The NOMOUNT clause starts the database instance without mounting the database. You cannot use the NOMOUNT clause with the MOUNT or OPEN options.

Command Examples

Example 1

The following examples show two different methods for starting a database instance. Each command starts a database instance using the standard parameter file, mounts the default database in exclusive mode, and opens the database.

DGMGRL> STARTUP;
DGMGRL> STARTUP OPEN;

Example 2

The following command shuts down the current instance, immediately restarts it without mounting or opening the database, and allows only users with restricted session privileges to connect to it.

DGMGRL > STARTUP FORCE RESTRICT NOMOUNT;

Example 3

The following command starts an instance using the parameter file testparm without mounting the database.

DGMGRL > STARTUP PFILE=testparm NOMOUNT;

Example 4

The following example starts and mounts a database instance, but does not open it.

DGMGRL> STARTUP MOUNT;

Note:
If the broker is enabled (DG_BROKER_START=TRUE) and the specified database is a primary database or a logical standby database, the broker will attempt to open the database if the database profile indicates the database should be opened.

STOP OBSERVER

Stops the fast-start failover observer.

Format

STOP OBSERVER;

Command Parameters

None.

Usage Notes

- You can issue this command while connected to any database in the broker configuration.

- This command does not disable fast-start failover.

- Fast-start failover does not need to be enabled when you issue this command.

- If fast-start failover is enabled when you issue the STOP OBSERVER command, then the primary and standby databases must be connected and communicating with each other. Otherwise the following error is returned:

ORA-16636 Fast-Start Failover target standby in error state, cannot stop observer

- If fast-start failover is not enabled when you issue the STOP OBSERVER command, then only the primary database must be running when you stop the observer.

- The observer does not stop immediately when the STOP OBSERVER command is issued. The observer does not discover is has been stopped until the next time the observer contacts the broker.

As soon as you have issued the STOP OBSERVER command, you may enter the START OBSERVER command again on any computer. You can start a new observer right away, even if the old observer has not yet discovered it was stopped. Any attempt to restart the old observer will fail, because a new observer has been registered with the broker configuration.

Command Examples

Example 1

The following example stops the observer.

DGMGRL> STOP OBSERVER;

SWITCHOVER

A switchover operation is a planned transition in which the primary database exchanges roles with one of the standby databases. When you issue the SWITCHOVER command, the current primary database becomes a standby database, and the specified standby database becomes the primary database.

Format

SWITCHOVER TO database-name;

Command Parameter

database-name

The name of the standby database you want to change to the primary database role.

Usage Notes

- If fast-start failover is enabled, you may switch over only to the target standby database and only when the observer is running.

- The broker verifies that the primary and standby databases are in the following states before starting the switchover:

- The primary database must be enabled and ONLINE, with redo transport services started.

- The standby database must be enabled and ONLINE, with log apply services started.

- The broker allows the switchover to proceed as long as there are no redo transport services errors for the standby database that you selected to participate in the switchover. However, errors occurring for any other standby database not involved in the switchover will not prevent the switchover from proceeding.

- Switchover to a logical standby database is not allowed when the configuration is running in maximum protection mode.

- If the broker configuration is in either MAXPROTECTION or MAXAVAILABILITY mode, the switchover maintains the protection mode even after the operation (described in Section 5.3.1). The switchover will not be allowed if the mode cannot be maintained because the target standby database of the switchover was the only standby that satisfied the protection mode requirement.

- If the standby database that is assuming the primary role is a physical standby database, then both the primary and standby databases will be restarted after the switchover completes. If the standby database is a logical standby database, then neither the primary database nor the logical standby database is restarted.

- If the standby database that is assuming the primary role is a physical standby database, then the original primary becomes a physical standby database. Otherwise, it becomes a logical standby database.

- If the primary database is a RAC database, the broker will keep only one instance running and shut down all other instances before it continues the switchover. If the standby database you want to switch to the primary role is a RAC database, the broker will shut down all instances except the apply instance before it continues the switchover. See Section 5.3 for details.

- If the standby database that is assuming the primary role is a logical standby database and there are physical standby databases in the configuration, after the switchover, the physical standby databases will be disabled until they are reenabled.

Caution:
For this reason, Oracle generally recommends that you specify your physical standby database for switchover instead of your logical standby database. If you must switch over to your logical standby database, see Section 5.4.3 to reenable your physical standby database.

Command Examples

Example 1

The following example shows a successful switchover in which the standby database, DR_Sales, transitions into the primary role.

DGMGRL> SWITCHOVER TO DR_Sales;
Performing switchover NOW, please wait...
Operation requires shutdown of instance "sales1" on database "North_Sales"
Shutting down instance "sales1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires shutdown of instance "dr_sales1" on database "DR_Sales"
Shutting down instance "dr_sales1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "sales1" on database "North_Sales"
Starting instance "sales1"...
ORACLE instance started.
Database mounted.
Operation requires startup of instance "dr_sales1" on database "DR_Sales"
Starting instance "dr_sales1"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "DR_Sales"

Example 2

If you connect to the database using operating system authentication, you can use any username and password to connect. However, DGMGRL may not be able to shut down and start up the primary and standby database automatically because it cannot remotely authenticate itself.

The following example shows a switchover that succeeded but returns an error because DGMGRL cannot shut down and start up the primary and standby databases.

DGMGRL> CONNECT /
Connected

DGMGRL> SWITCHOVER TO "DR_Sales";
Performing switchover NOW, please wait...
Operation requires shutdown of instance "sales1" on database "North_Sales"
Shutting down instance "sales1"...
ORA-01017: invalid username/password; logon denied

You are no longer connected to ORACLE
Please connect again.
Unable to shut down instance "sales1"
You must shut down instance "sales1" manually
Operation requires shutdown of instance "dr_sales1" on database "DR_Sales"
You must shut down instance "dr_sales1" manually.
Operation requires startup of instance "sales1" on database "North_Sales"
You must start instance "sales1" manually.
Operation requires startup of instance "dr_sales1" on database "DR_Sales"
You must start instance "dr_sales1" manually.
Switchover succeeded, new primary is "DR_Sales"

Note:
For DGMGRL to restart instances automatically, you must connect to the database as SYSDBA using the username and password you specified in the remote password file before you begin the switchover. The username and password must be the same on the primary and standby databases.

You must manually issue the SHUTDOWN and STARTUP commands to restart the new primary and standby database instances in this configuration.

9 Database Properties

Database properties help you to view and control the behavior of databases, redo transport services, and log apply services in a broker configuration. This chapter provides the following sections about the monitorable and configurable properties:

- Section 9.1, "Monitorable (Read-Only) Database Properties"

- Section 9.2, "Configurable Database Properties"

The scope of some properties is said to be database-wide. If the database (primary or standby) is a RAC database consisting of multiple instances, the value of such a property applies uniformly across all of the instances sharing that database. The scope of other properties is said to be instance-specific. Such a property exists for all instances of the RAC database, but its value may differ from one specific instance to another.

Note:
This chapter presents properties primarily from the point of view of the Data Guard command-line interface (DGMGRL). Using DGMGRL, the properties described in this chapter may be viewed or modified using discrete DGMGRL commands.
Enterprise Manager explicitly presents some of these properties on the Edit Properties page. Information from other properties may be implicitly incorporated into other Web pages displayed by Enterprise Manager. Each property's description in this chapter indicates how Enterprise Manager presents that property.

9.1 Monitorable (Read-Only) Database Properties

Monitorable properties allow you to view information related to the database or the instance, but you cannot change the values of these properties. You can view all of the monitorable properties using the DGMGRL SHOW commands.

Note:
Information for monitorable properties can be seen only when broker management of the database is enabled and the database is in an online state. Enterprise Manager displays the information obtained from these properties on the Property page.

If the database is a RAC database, the output values of some properties may also show instance-specific information. For example if the primary database is a RAC database, LogXptStatus may show Instance1 transmitting redo data to Standby2 has an error and Instance2 transmitting redo data to Standby4 has an error.

The following sections describe the database monitorable properties:

- InconsistentLogXptProps (Inconsistent Redo Transport Properties)

- InconsistentProperties (Inconsistent Database Properties)

- LogXptStatus (Redo Transport Status)

- LsbyFailedTxnInfo (Logical Standby Failed Transaction Information)

- LsbyParameters (Logical Standby Parameters)

- LsbySkipTable (Logical Standby Skip Table)

- LsbySkipTxnTable (SQL Apply Skip Transaction Table)

- RecvQEntries (Receive Queue Entries)

- SendQEntries (Send Queue Entries)

- StatusReport (Status Report)

- TopWaitEvents

9.1.1 InconsistentLogXptProps (Inconsistent Redo Transport Properties)

The InconsistentLogXptProps property returns a table that shows all properties related to redo transport services whose values are inconsistent between the broker configuration file and the runtime value in the database.

The properties reported in this table can be either database-specific properties or instance-specific properties. A database-specific property only ensures that there is one value in the broker's configuration file for all instances sharing the database, but the runtime values among the instances can be different. This means that a database-specific property may be inconsistent only on some instances.

This property pertains to the primary database. The table contains the following columns:

- INSTANCE_NAME

The value matching the SID for the instance.

- STANDBY_NAME

The database unique name (DB_UNIQUE_NAME) of the standby database to which this redo transport services property pertains.

- PROPERTY_NAME

The name of the redo transport services property with an inconsistent value.

- MEMORY_VALUE

The runtime value being used in the database.

- BROKER_VALUE

The value of the redo transport services property saved in the broker configuration file.

9.1.2 InconsistentProperties (Inconsistent Database Properties)

The InconsistentProperties property returns a table that shows all database properties whose values contained in the broker configuration file are inconsistent with the values in the corresponding server parameter file or the runtime values in the database.

The properties reported in this table can be either database-specific properties or instance-specific properties. A database-specific property only ensures that there is one value in the broker's configuration file for all instances sharing the database, but the runtime memory values or SPFILE values among the instances can be different. This means that a database-specific property may be inconsistent only on some instances.

Each individual database has this property. The table contains the following columns:

- INSTANCE_NAME

The value matching the SID for the instance.

- PROPERTY_NAME

The name of the database property with the inconsistent value.

- MEMORY_VALUE

The corresponding runtime value being used in the database.

- SPFILE_VALUE

The corresponding value saved in the server parameter file (SPFILE).

- BROKER_VALUE

The value of the database property saved in the broker configuration file.

9.1.3 LogXptStatus (Redo Transport Status)

The LogXptStatus property returns a table that contains the error status of redo transport services for each of the enabled standby databases. This property pertains to the primary database.

The table contains the following columns:

- PRIMARY_INSTANCE_NAME

The value matching the SID for the instance on the primary database.

- STANDBY_DATABASE_NAME

The database unique name (DB_UNIQUE_NAME) of the standby database.

- ERROR

The text of the redo transport error. If there is no error, the field is empty.

Each entry in the table indicates the status of redo transport services on one primary instance to one standby database.

The format of the error status is as follows:

"standby1_sitename=error_status, standby2_sitename=error_status,..."

The error status can be an empty string, which indicates there is no error.

In the following example, the STATUS from DR_Sales is empty because there is no error for the DR_Sales destination. The South_Report destination returned the ORA-01034 message.

DGMGRL> SHOW DATABASE 'North_Sales' 'LogXptStatus' ;
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME               STATUS
sales1            DR_Sales
sales1        South_Report      ORA-01034: ORACLE not available

9.1.4 LsbyFailedTxnInfo (Logical Standby Failed Transaction Information)

The LsbyFailedTxnInfo property identifies a failed transaction that caused log apply services to stop. This property contains a string with the following values from the DBA_LOGSTDBY_EVENTS view:

- XIDUSN: Transaction ID undo segment number

- XIDSLT: Transaction ID slot number

- XIDSQN: Transaction ID sequence number

- STATUS_CODE: Status (or Oracle error code) belonging to the STATUS message

- STATUS: Description of the current activity of the process or the reason why log apply services stopped

The transaction IDs and status information are separated by a string of number signs (###). This property pertains to a logical standby database.

9.1.5 LsbyParameters (Logical Standby Parameters)

The LsbyParameters property contains a string that identifies the value of MAX_SGA (maximum system global area) and MAX_SERVERS (maximum number of parallel query servers) specifically reserved for log apply services. These values are separated by a string of number signs (###) in the LsbyParameters property.

This property pertains to a logical standby database.

9.1.6 LsbySkipTable (Logical Standby Skip Table)

The LsbySkipTable property lists the SQL Apply skip specifications. These skip specifications specify filters for SQL Apply to skip applying a certain class of online redo log files on the logical standby database. This property returns a table with the following columns from the DBA_LOGSTDBY_SKIP view:

- ERROR

Indicates if the statement should be skipped (Y) or if errors should be returned for the statement (N)

- STATEMENT_OPT

Indicates the type of statement that should be skipped

- SCHEMA

The schema name for which this skip option should be used

- NAME

Name of the object for which this skip option should be used

- PROCEDURE

Name of the stored procedure to execute when processing the skip option

9.1.7 LsbySkipTxnTable (SQL Apply Skip Transaction Table)

The LsbySkipTxnTable lists the skip settings chosen. This property returns a table with following columns:

- XIDUSN: Transaction ID undo segment number

- XIDSLT: Transaction ID slot number

- XIDSQN: Transaction ID sequence number

- ACTIVE: Description of the current activity of the process or the reason why SQL Apply stopped

This property pertains to SQL Apply.

9.1.8 RecvQEntries (Receive Queue Entries)

The RecvQEntries property returns a table indicating all log files that were received by the standby database but have not yet been applied. If no rows are returned, it implies all log files received have been applied. This property pertains to a standby database.

The table contains the following columns in the order shown:

- STATUS

The STATUS column is set to one of the following values for a log file on a logical standby database:

- NOT_APPLIED: No redo records in this log file have been applied.

- PARTIALLY_APPLIED: Some of the redo records in this log file have been applied while others have not.

- COMMITTED_TRANSACTIONS_APPLIED: This status value only applies to a logical standby database. All redo records belonging to the committed transactions have been applied. Redo records belonging to uncommitted transactions have not been read by LogMiner and may still be needed when the transactions are committed in the future. Therefore, it is not safe yet to discard this online redo log file.

- RESETLOGS_ID

Resetlogs identifier associated with the archived redo log file

- THREAD

The redo thread number

- LOG_SEQ

The online redo log file sequence number

- TIME_GENERATED

The first time when the online redo log file was written to the primary database

- TIME_COMPLETED

The next time when the log file was archived on the primary database (corresponds to the NEXT_CHANGE# column)

- FIRST_CHANGE#

First change number in the archived redo log file

- NEXT_CHANGE#

First change in the next log file

- SIZE (KBs)

The SIZE of the online redo log file in kilobytes

For example:

DGMGRL> SHOW DATABASE 'DR_Sales' 'RecvQEntries' ;
STATUS     RESETLOGS_ID           THREAD
LOG_SEQ          TIME_GENERATED       TIME_COMPLETED    FIRST_CHANGE#
NEXT_CHANGE#        SIZE (KBs)
NOT_APPLIED        497198843                1                    5
06/20/2003 14:55:38  06/20/2003 16:31:26           202138
210718             7364
NOT_APPLIED        497198843                1                    6
06/20/2003 16:31:26  06/20/2003 16:31:39           210718
210753               13
NOT_APPLIED        497198843                1                    7
06/20/2003 16:31:39  06/20/2003 16:31:54           210753
210758                1
NOT_APPLIED        497198843                1                    8
06/20/2003 16:31:54  06/20/2003 16:31:59           210758
210789               11

Note:
Enterprise Manager displays this information on the Log File Details page.

9.1.9 SendQEntries (Send Queue Entries)

The SendQEntries property returns a table that shows all log files on the primary database that were not successfully archived to one or more standby databases. This property pertains to the primary database.

The table contains the following columns:

- STANDBY_NAME

The value can be empty or it can contain the database unique name (DB_UNIQUE_NAME) of the standby database. If empty, the STATUS column will contain a value of CURRENT or NOT_ARCHIVED.

- STATUS

The STATUS column is set to one of the following values:

- CURRENT: A log file to which online redo is currently being written.

- NOT_ARCHIVED: A completed online redo log file that has not been archived locally.

- ARCHIVED: A completed log file that has been archived locally but has not been transmitted to the standby database specified in the STANDBY_NAME column.

The table contains exactly one row with the value of STATUS=CURRENT. There can be multiple rows with the value STATUS=ARCHIVED or STATUS=NOT_ARCHIVED.

- RESETLOGS_ID

Resetlogs identifier associated with the archived redo log file

- THREAD

The redo thread number.

- LOG_SEQ

The log sequence number. Multiple rows may have the same LOG_SEQ value (for different STANDBY_NAME values).

- TIME_GENERATED

The first time when the online redo log file was written to the primary database.

- TIME_COMPLETED

The next time when the log file was archived on the primary database (corresponds to the NEXT_CHANGE# column).

- FIRST_CHANGE#

First change number in the archived redo log file.

- NEXT_CHANGE#

First change in the next log file.

- SIZE (KBs)

The SIZE of the online redo log file in kilobytes.

For example, the following shows output from a SHOW DATABASE command:

DGMGRL> SHOW DATABASE 'North_Sales' 'SendQEntries' ;
PRIMARY_SEND_QUEUE
STANDBY_NAME       STATUS     RESETLOGS_ID
THREAD              LOG_SEQ       TIME_GENERATED       TIME_COMPLETED
FIRST_CHANGE#     NEXT_CHANGE#       SIZE (KBs)
sales1     ARCHIVED        497198843
1                    9  06/20/2003 16:31:59  06/20/2003 16:39:57
210789           211411              186
sales1     ARCHIVED        497198843
1                   10  06/20/2003 16:39:57  06/20/2003 16:40:01
211411           211415                1
sales1     ARCHIVED        497198843
1                   11  06/20/2003 16:40:01  06/20/2003 16:40:07
211415           211418                1
CURRENT        497198843
1                   12  06/20/2003 16:40:07
211418                                 1

Note:
Enterprise Manager displays this information on the Log File Details page.

9.1.10 StatusReport (Status Report)

The StatusReport property returns a table that provides a list of errors or warnings about the status of the database. In a RAC database environment, it also includes the status of all running instances. Each individual database has this property. The table contains the following columns in the order shown:

- INSTANCE_NAME

The value matching the SID for the instance.

- ERROR_TEXT

Formatted error text.

- SEVERITY

The severity of the error message. The value is either WARNING or ERROR.

For example, the following shows output from a SHOW DATABASE command:

DGMGRL> SHOW DATABASE 'North_Sales' 'StatusReport' ;
STATUS REPORT
INSTANCE_NAME   SEVERITY ERROR_TEXT
sales1      ERROR ORA-16737: the redo transport service for
standby "DR_Sales" has an error
*      ERROR ORA-16745: unable to add DB_UNIQUE_NAME DR_Sales
into The DG_CONFIG list because it is full

9.1.11 TopWaitEvents

Specifies the 5 events with the longest waiting time in the specified instance. The events and their waiting time are retrieved from V$SYSTEM_EVENT. Each instance in the configuration has this property. This property is an instance level monitorable property. The table contains the following columns in the order shown:

- Event

The system wait event.

- Wait Time

The total amount of time waited for this event in hundredths of a second.

See Also:
See Oracle Database Reference for detailed explanations of all system wait events.

The following example shows output from a SHOW INSTANCE command:

DGMGRL> SHOW INSTANCE sales1 'TopWaitEvents';
TOP SYSTEM WAIT EVENTS
Event            Wait Time
rdbms ipc message               671350
SQL*Net message from client         62390
pmon timer                47897
Queue Monitor Wait                43016
wakeup time manager                38508

9.2 Configurable Database Properties

Configurable database properties control the behavior of databases in a broker configuration. You can view and dynamically update the values of these properties using either DGMGRL or Enterprise Manager. However, some properties can only be updated through DGMGRL.

In most cases, the configurable database property is said to have database scope; meaning the value you set for the property applies uniformly to each instance of the database. However, in a few cases, the configurable database property is said to have instance scope; meaning, for a multiple-instance database environment, it is possible that the values of some particular properties may differ from one instance of the database to the next. Table 9-1 lists each configurable database property and indicates if the scope of the property is database-wide or instance-specific. If the Scope column contains:

- Database—The value of the property is database wide, not instance or configuration specific.

- Instance—The value of the property is instance specific, not database or configuration specific.

- Configuration—The value of the property is configuration wide, not instance or database specific.

Table 9-1 Configurable Properties

Configurable Property Name

Scope

Pertains To

AlternateLocation

Instance

Redo transport services

ApplyInstanceTimeout

Database

Redo Apply and SQL Apply

ApplyParallel

Database

Redo Apply

ArchiveLagTarget

Database

Redo transport services

Binding

Database

Redo transport services

DbFileNameConvert

Database

Redo transport services

DelayMins

Database

Redo Apply and SQL Apply

Dependency

Database

Redo transport services

FastStartFailoverTarget

Database

Fast-start failover

FastStartFailoverThreshold

Configuration

Fast-start failover

HostName

Instance

Instance identification

InitialConnectIdentifier

Database

Broker communication

LocalListenerAddress

Instance

Broker communication

LogArchiveFormat

Instance

Redo transport services

LogArchiveMaxProcesses

Database

Redo transport services

LogArchiveMinSucceedDest

Database

Redo transport services

LogArchiveTrace

Instance

Diagnosis

LogFileNameConvert

Database

Redo transport services

LogShipping

Database

Redo transport services

LogXptMode

Database

Redo transport services

LsbyASkipCfgPr

Database

SQL Apply

LsbyASkipErrorCfgPr

Database

SQL Apply

LsbyASkipTxnCfgPr

Database

SQL Apply

LsbyDSkipCfgPr

Database

SQL Apply

LsbyDSkipErrorCfgPr

Database

SQL Apply

LsbyDSkipTxnCfgPr

Database

SQL Apply

LsbyMaxEventsRecorded

Database

SQL Apply

LsbyMaxSga

Instance

SQL Apply

LsbyMaxServers

Instance

SQL Apply

LsbyRecordAppliedDdl

Database

SQL Apply

LsbyRecordSkipDdl

Database

SQL Apply

LsbyRecordSkipErrors

Database

SQL Apply

LsbyTxnConsistency

Database

SQL Apply

MaxConnections

Database

Primary

MaxFailure

Database

Redo transport services

NetTimeout

Database

Redo transport services

PreferredApplyInstance

Database

Redo Apply and SQL Apply

ReopenSecs

Database

Redo transport services

SidName

Instance

Instance identification

StandbyArchiveLocation

Instance

Redo transport services

StandbyFileManagement

Database

Redo Apply and SQL Apply

See Also:
Chapter 4 for more information about database property management

Note:
When a broker configuration with its primary database is created and standby databases are added to the configuration, the broker imports existing settings from the databases to set many of the properties. If importing an existing setting fails, or if a property value is not imported, then the broker uses a broker default value. The default values and whether or not a property is imported is indicated within each property description.

9.2.1 AlternateLocation

Specifies an alternate disk location to store the archived redo log files in the standby when the location specified by the StandbyArchiveLocation fails. The property has an instance scope, and the location it specifies has to be accessible by the instance.

Category

Description

Datatype

String

Valid values

Directory specification on system where the standby instance is located

Broker default

Empty string

Imported?

No

Parameter class

Dynamic

Role

StandbyFoot 1

Standby type

Physical or logical

Corresponds to ...

- On the standby instance, the LOCATION attribute for the LOG_ARCHIVE_DEST_n initialization parameter that represents an alternate destination of the local destination that matches the property StandbyArchiveLocation

- On the primary database, the TEMPLATE attribute for the LOG_ARCHIVE_DEST_n initialization parameter that represents an alternate destination

Scope

Instance

Enterprise Manager name

Alternate Standby Location

Footnote 1 Although this property is set for the standby instance, it is indirectly related to redo transport services for the primary database. The broker sets up both an alternate local destination on the standby instance and an alternate remote destination on the primary database.

Note:
On a logical standby database, Oracle recommends the LOCATION attribute of the LOG_ARCHIVE_DEST_n initialization parameter for the local destination be different from the value of AlternateLocation property.

9.2.2 ApplyInstanceTimeout

Specifies the number of seconds the broker waits after detecting the current apply instance failed and before initiating the apply instance failover.

Category

Description

Datatype

Integer

Valid values

>=0 (seconds)

Broker default

0 (results in immediate apply instance failover)

Imported?

No

Parameter class

Not applicable

Role

Standby

Standby type

Physical or logical

Corresponds to ...

Not applicable

Scope

Database

Enterprise Manager name

Not applicable

9.2.3 ApplyParallel

Specifies whether Redo Apply should use multiple processes to apply redo data to the physical standby database. If Redo Apply is offline, then setting the property has no immediate effect. However, when Redo Apply is online again, the value of the property is used to determine the parallel apply behavior of Redo Apply.

Category

Description

Datatype

String

Valid values

- AUTO—the number of parallel processes used for Redo Apply is automatically determined by Oracle based on the number of CPUs that the system has.

- NO—no parallel apply.

Broker default

AUTO

Imported?

No

Parameter class

Not applicable

Role

Standby

Standby type

Physical

Corresponds to ...

- AUTO corresponds to the PARALLEL clause of the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement

- NO corresponds to the NOPARALLEL clause of the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement

Scope

Database

Enterprise Manager name

Not applicable

9.2.4 ArchiveLagTarget

Limits the amount of data that can be lost and effectively increases the availability of the standby database by forcing a log switch after the amount of time you specify (in seconds) elapses. That way, the standby database will not miss redo records generated from a time range longer than the value set for the ARCHIVE_LAG_TARGET initialization parameter.

Category

Description

Datatype

Number

Valid values

Seconds (either 0 seconds, or any number from 60 to 7200 seconds)

Broker default

0 (disabled)

Imported?

Yes, from the ARCHIVE_LAG_TARGET initialization parameter

Parameter class

Dynamic

Role

Primary

Standby type

Not applicable

Corresponds to ...

ARCHIVE_LAG_TARGET=seconds initialization parameter

Scope

Database

Enterprise Manager name

Archive Lag Target

9.2.5 Binding

Specifies whether or not the standby destination is MANDATORY or OPTIONAL.

Category

Description

Datatype

String

Valid values

- MANDATORY
You can specify a policy for reuse of online redo log files using the MANDATORY value. If the archiving operation of a mandatory destination fails, online redo log files cannot be overwritten.

- OPTIONAL

You can specify a policy for reuse of online redo log files using the OPTIONAL value. If the archiving operation of an optional destination fails, the online redo log files are overwritten.

Broker default

OPTIONAL

Imported?

Yes, from the BINDING column of the V$ARCHIVE_DEST view of the primary database

Parameter class

Dynamic

Role

StandbyFoot 1

Standby type

Physical and logical

Corresponds to ...

- MANDATORY and OPTIONAL attributes for the LOG_ARCHIVE_DEST_n initialization parameter of the primary database

- BINDING column of the V$ARCHIVE_DEST view of the primary database

Scope

Database

Enterprise Manager name

Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_n value of the primary database.

9.2.6 DbFileNameConvert

Distinguishes standby datafile filenames from primary datafile filenames. You must set this property on all standby databases. If you add a datafile to the primary database, this property converts the datafile name on the primary database to the datafile on the standby database.

This property is used in the following situations:

- At standby mount time, it is used to rename primary datafile filenames to standby datafile filenames if the datafile file path on the standby system is different from the primary database system.

- When a new data file is created on the primary database, a corresponding new data file will be created on the standby database if the StandbyFileManagement property is set to 'AUTO'. Oracle uses the data-file file-path mapping information from the DbFileNameConvert property to determine the standby file path of the new standby data file. If the StandbyFileManagement property is set to 'MANUAL', you must add a corresponding file to the standby database.

Category

Description

Datatype

String

Valid values

Set the value of this property to a list of string pairs:

1. The first string is the substring found in the datafile names on the primary database.

2. The second string is the substring found in the datafile names on the standby database.

For example, ('string1', 'string2', 'string3', 'string4',...)

Where:

- string1 is the substring of the primary database filename.

- string2 is the substring of the standby database filename.

- string3 is the substring of the primary database filename.

- string4 is the substring of the standby database filename.

Broker default

' '

Imported?

Yes, from the DB_FILE_NAME_CONVERT initialization parameter

Parameter class

Static

Role

Standby

Standby type

Physical

Corresponds to ...

DB_FILE_NAME_CONVERT initialization parameter

Scope

Database

Enterprise Manager name

DB File Name Convert

9.2.7 DelayMins

Specifies the number of minutes log apply services will delay applying the archived redo log files on the standby database. When the DelayMins property is set to the default value of 0 minutes, log apply services apply redo data as soon as it is received, using real-time apply if the standby database is configured with standby redo logs.

If the DelayMins property is set to 0 and standby redo logs are configured on the standby database, start log apply services as follows:

- Start Redo Apply on physical standby databases using the following SQL statement:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

- Start SQL Apply on logical standby databases using the following SQL statement:

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

If the DelayMins property is set to 0 but standby redo logs are not configured on the standby database, start log apply services as follows:

- Start Redo Apply on physical standby databases using the following SQL statement:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

- Start SQL Apply on logical standby databases using the following SQL statement:

ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

Category

Description

Datatype

Integer

Valid values

>=0 (minutes)

Broker default

0

Imported?

Yes, from the DELAY_MINS column of the V$ARCHIVE_DEST view of the primary database

Parameter class

Dynamic

Role

StandbyFoot 1

Standby type

Physical and logical

Corresponds to ...

- DELAY attribute for the LOG_ARCHIVE_DEST_n initialization parameter of the primary database

- DELAY_MINS column of the V$ARCHIVE_DEST view of the primary database

- Options used to start Redo Apply and SQL Apply

Scope

Database

Enterprise Manager name

Apply Delay (mins)

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_n value of the primary database.

9.2.8 Dependency

Specifies the database unique (DB_UNIQUE_NAME) name (can be the primary or a standby database name) on which this database depends for receiving archived redo log files.

Category

Description

Datatype

String

Valid values

Database unique name (DB_UNIQUE_NAME), except for the standby database itself, or you can set this property to an empty string.

Broker default

' '

Imported?

No

Parameter class

Dynamic

Role

StandbyFoot 1

Standby type

Physical or logical

Corresponds to ...

DEPENDENCY attribute for the LOG_ARCHIVE_DEST_n initialization parameter of the primary database

Scope

Database

Enterprise Manager name

Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_n value of the primary database.

See Also:
Oracle Data Guard Concepts and Administration

9.2.9 FastStartFailoverTarget

Specifies the DB_UNIQUE_NAME of the database that will be the target of a fast-start failover when this database is the primary database. See Step 2 in Section 5.5.2 for more information about setting this property.

Category

Description

Datatype

String

Valid Values

DB_UNIQUE_NAME of the database that is the target of the fast-start failover.

Broker default

If only one standby database exists, then the broker selects that as the default value for this property on the primary database when fast-start failover is enabled. If more than one standby database exists, you must specify the FastStartFailoverTarget value explicitly, prior to enabling fast-start failover.
For the target standby database, the broker automatically selects the current primary database as the value for this property when fast-start failover is enabled.

Imported

No

Parameter class

Not applicable

Role

Primary or standby

Standby type

Physcial or logical

Corresponds to ...

Not applicable

Scope

Database

Enterprise Manager name

Enterprise Manager displays the value for the current primary database on the Data Guard Overview page, along with whether or not fast-start failover has been enabled.

9.2.10 FastStartFailoverThreshold

Defines the number of seconds the observer attempts to reconnect to the primary database before initiating a fast-start failover to the target standby database. The time interval starts when the observer first detects conditions for triggering a fast-start failover (described in Section 5.5.6). If the observer is unable to regain a connection to the primary database within the specified time, then the observer begins a fast-start failover. See Step 3 in Section 5.5.2 for more information about setting this property.

Category

Description

Datatype

Integer

Valid Value

Integral number of seconds. Must be greater than zero.

Broker default

30 seconds

Imported

No

Parameter class

Not applicable

Role

Target standby database that is about to fail over to the primary role

Standby type

Physical or logical

Corresponds to ...

Not applicable

Scope

Broker configuration. This value will be consumed by the observer after fast-start failover has been enabledFoot 1

Enterprise Manager name

Oracle Enterprise Manager presents this as "Fast-Start Failover Threshold" on the Data Guard Overview page.

Footnote 1 If you specify FastStartFailoverThreshold when fast-start failover is enabled, the observer will recognize the new value the next time it contacts the primary database.

9.2.11 HostName

Specifies the name of the host on which the instance is running. The property can only be updated when broker management of the database is disabled. You should only update the value when the host is renamed, in which case you need to disable broker management of the database, update the HostName property to match with the new host name, and then reenable broker management of the database.

Note:
If the value of the HostName property does not match the actual name of the host, broker management of the database cannot be enabled.

Category

Description

Datatype

String

Valid values

Name of the host on which the instance is running

Broker default

Not applicable

Imported?

Yes

Parameter class

Not applicable

Role

Primary and standby

Standby type

Physical or logical

Corresponds to ...

HOST_NAME column of the V$INSTANCE view

Scope

Instance

Enterprise Manager name

Not applicable

9.2.12 InitialConnectIdentifier

Specifies the initial connection identifier the broker uses to make the first connection to a database. If using DGMGRL, you supply the value when you enter the CREATE CONFIGURATION or ADD DATABASE command. If using Enterprise Manager, the value is supplied automatically. You should only update the value of this property when the original value has an error.

Category

Description

Datatype

String

Valid values

A connect identifier that can be used to connect to this database

Broker default

Not applicable

Imported?

No

Parameter class

Not applicable

Role

Primary and standby

Standby type

Physical or logical

Corresponds to ...

Not applicable

Scope

Database

Enterprise Manager name

Not applicable

9.2.13 LocalListenerAddress

Specifies the listener address at which the instance is registered. The property can only be updated when broker management of the database is disabled. You should only update the value when the LOCAL_LISTENER initialization parameter value is being changed, in which case you need to:

1. Disable broker management of the database

2. Update the LOCAL_LISTENER initialization parameter value

3. Update the LocalListenerAddress property in listener ADDRESS format to match with the new LOCAL_LISTENER address

4. Reenable broker management of the database

In the event that the LOCAL_LISTENER initialization parameter value of instances belonging to more than one database is being changed, it is recommended to:

1. Disable the configuration

2. Make the LOCAL_LISTENER initialization parameter value changes at all of the instances

3. Make the LocalListenerAddress property changes for all of the affected instances

4. Enable the configuration

Note:
If the value of the LocalListenerAddress property does not match the actual address of the listener at which the instance is registered, broker management of the database cannot be enabled.

Category

Description

Datatype

String

Valid values

Listener address, in ADDRESS format

Broker default

Same as the default value for the LOCAL_LISTENER address initialization parameter.

Imported?

Yes, from the LOCAL_LISTENER initialization parameter and translated into ADDRESS format if the initialization parameter value is a new service name

Parameter class

Dynamic

Role

Primary and standby

Standby type

Physical or logical

Corresponds to ...

LOCAL_LISTENER initialization parameter

Scope

Instance

Enterprise Manager name

Not applicable

9.2.14 LogArchiveFormat

Specifies the format for filenames of archived redo log files using a database ID (%d), thread (%t), sequence number (%s), and resetlogs ID (%r).

Category

Description

Datatype

String

Valid values

%d_%t_%s_%r

Broker default

Empty string

Imported?

Yes, from the LOG_ARCHIVE_FORMAT initialization parameter on the primary database

Parameter class

Static

Role

Primary and standby

Standby type

Physical and logical

Corresponds to ...

LOG_ARCHIVE_FORMAT initialization parameter

Scope

Instance

Enterprise Manager name

Not applicable

9.2.15 LogArchiveMaxProcesses

Specifies the initial number of archiver processes (ARCn) the Oracle database invokes. The actual number of archiver processes in use may increase subsequently based on the archiving workload.

Category

Description

Datatype

Integer

Valid values

1 to 30

Broker default

2

Imported?

Yes, from the LOG_ARCHIVE_MAX_PROCESSES initialization parameter

Parameter class

Dynamic

Role

Primary and standby

Standby type

Physical and logical

Corresponds to ...

LOG_ARCHIVE_MAX_PROCESSES initialization parameter

Scope

Database

Enterprise Manager name

Archiver Processes

9.2.16 LogArchiveMinSucceedDest

Controls when online redo log files are available for reuse. For the online redo log files to be available for reuse, archiving must succeed to a minimum number of destinations.

Category

Description

Datatype

Integer

Valid values

1 to 10

Broker default

1

Imported?

Yes, from the LOG_ARCHIVE_MIN_SUCCEED_DEST initialization parameter

Parameter class

Dynamic

Role

Primary

Standby type

Not applicable

Corresponds to ...

LOG_ARCHIVE_MIN_SUCCEED_DEST initialization parameter

Scope

Database

Enterprise Manager name

Not applicable

9.2.17 LogArchiveTrace

Set this property to an integer value to see the progression of the archiving of online redo log files on the primary and the standby databases. The Oracle database writes an audit trail of the archived redo log files received from the primary database into process trace files.

Category

Description

Datatype

Integer

Valid values

A valid value is the sum of any combination of any of the following values:
0: Disable archive redo log tracing

1: Track archiving of online redo log file

2: Track archiving status of each archive redo log destination

4: Track archiving operational phase

8: Track ARCHIVELOG destination activity

16: Track detailed ARCHIVELOG destination activity

32: Track ARCHIVELOG destination parameter modifications

64: Track ARCn process state activity

128: Track FAL (fetch archive log) server related activities

256: Tracks RFS Logical Client

512: Tracks LGWR redo shipping network activity

1024: Tracks RFS physical client

2048: Tracks RFS/ARCn ping heartbeat

4096: Tracks real-time apply activity

8192: Tracks Redo Apply (media recovery or physical standby)

Broker default

255

Imported?

Yes, from the LOG_ARCHIVE_TRACE initialization parameter

Parameter class

Dynamic

Role

Primary and standby

Standby type

Physical and logical

Corresponds to...

LOG_ARCHIVE_TRACE initialization parameter

Scope

Instance

Enterprise Manager name

Log Archive Trace

9.2.18 LogFileNameConvert

Converts the filename of an online redo log file on the primary database to the filename of a corresponding online redo log file on the standby database.

Category

Description

Datatype

String

Valid values

Set the value of this property to a list of an even number of string pairs, separated by commas.

1. The first string is the substring found in the datafile names on the primary database.

2. The second string is the substring found in the datafile names on the standby database.

For example, ('string1', 'string2', 'string3', 'string4',...)

Where:

- string1 is the substring of the primary database filename.

- string2 is the substring of the standby database filename.

- string3 is the substring of the primary database filename.

- string4 is the substring of the standby database filename.

Broker default

' '

Imported?

Yes, from the LOG_FILE_NAME_CONVERT initialization parameter

Parameter class

Static

Role

Standby

Standby type

Physical

Corresponds to ...

LOG_FILE_NAME_CONVERT initialization parameter

Scope

Database

Enterprise Manager name

Log File Name Convert

9.2.19 LogShipping

Specifies whether or not redo transport services can send archived redo log files to the particular standby database. The broker uses the value of the LogShipping property only when the primary database is in the ONLINE state:

- If the primary database is in the LOG-TRANSPORT-OFF state, then redo transport services are offline to all standby databases, regardless of whether or not the LogShipping property is set to ON or OFF.

- If the primary database is in the ONLINE state and the value of the LogShipping property is ON, then redo transport services are enabled to send archived redo log files to the particular standby database. If the LogShipping property is OFF, then redo transport services are disabled to send archived redo log files to the particular standby database.

Category

Description

Datatype

String

Valid values

ON or OFF

Broker default

ON

Imported?

No

Parameter class

Dynamic

Role

StandbyFoot 1

Standby type

Physical and logical

Corresponds to ...

ENABLE and DEFER values for the LOG_ARCHIVE_DEST_STATE_n initialization parameter of the primary database

Scope

Database

Enterprise Manager name

Log Shipping

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_n value of the primary database.

9.2.20 LogXptMode

Enables you to set the redo transport service. You set the redo transport services on each standby database to one of the following modes:

- SYNC

Configures redo transport services for this standby database using the LGWR, SYNC, and AFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. Standby redo log files are required. This mode is required for the maximum protection or maximum availability data protection modes. This redo transport service enables the highest grade of data protection to the primary database, but also incurs the highest performance impact.

- ASYNC

Configures redo transport services for this standby database using the LGWR, ASYNC, and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. Standby redo log files are required. This mode enables a moderate grade of data protection to the primary database, and incurs a lower performance impact than SYNC.

- ARCH

Configures redo transport services for this standby database using the ARCH attribute of the LOG_ARCHIVE_DEST_n initialization parameter. Standby redo log files are not required. This mode enables the lowest grade of data protection to the primary database, and incurs the lowest performance impact. This is the default setting.

Category

Description

Datatype

String

Valid values

SYNC or ASYNC or ARCH

Broker default

- ASYNC for standby databases with standby redo log files

- ARCH for standby databases without standby redo log files

Imported?

Yes, from the ARCHIVER, TRANSMIT_MODE, and AFFIRM columns of V$ARCHIVE_DEST view of the primary database

Parameter class

Dynamic

Role

StandbyFoot 1

Standby type

Physical or logical

Corresponds to ...

- ARCH, LGWR, SYNC, ASYNC, AFFIRM, and NOAFFIRM attributes for the LOG_ARCHIVE_DEST_n initialization parameter of the primary database

- ARCHIVER, TRANSMIT_MODE, and AFFIRM columns of V$ARCHIVE_DEST view of the primary database

Scope

Database

Enterprise Manager name

Redo Transport Service

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_n value of the primary database.

See Also:
Chapter 4 for more information about setting data protection modes for redo transport services

9.2.21 LsbyASkipCfgPr

Provides a way to add a skip specification to SQL Apply to control the apply service to skip (ignore) SQL statements that you do not want to apply to the logical standby database. The SKIP operation:

- Sets the criteria for identifying the SQL statements that will not be applied to the standby database

- Specifies any additional processing that will be done, if necessary

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category

Description

Datatype

String

Valid values

A valid set of arguments to the DBMS_LOGSTDBY.SKIP procedure

Broker default

Empty string

Imported?

No

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.SKIP procedure

Scope

Database

Enterprise Manager name

Add Skip Table Entries

See Also:
Oracle Database PL/SQL Packages and Types Reference

9.2.22 LsbyASkipErrorCfgPr

Adds a skip error specification to SQL Apply. It provides criteria to determine if an error should cause SQL Apply to stop. All errors to be skipped are stored in system tables that describe how exceptions should be handled.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category

Description

Datatype

String

Valid values

A valid set of arguments to the DBMS_LOGSTDBY.SKIP_ERROR procedure. The string must contain comma separators between the arguments.

Broker default

Empty string

Imported?

No

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.SKIP_ERROR procedure

Scope

Database

Enterprise Manager name

Add Skip Table Entries

See Also:
Oracle Database PL/SQL Packages and Types Reference

9.2.23 LsbyASkipTxnCfgPr

Skips over a transaction that caused SQL Apply to stop applying transactions to the logical standby database. This property enables you to specify the transaction ID (XIDSQN NUMBER) of the problematic transaction that you want SQL Apply to ignore. Before you restart SQL Apply, you should issue a SQL transaction that will correctly update the logical standby database in place of the skipped transaction. Applying a compensating transaction will help keep the logical standby database transactionally consistent with the primary database.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category

Description

Datatype

String

Valid values

A valid set of arguments to the DBMS_LOGSTDBY.SKIP_TRANSACTION procedure. Use comma separators between the arguments.

Broker default

Empty string

Imported?

No

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.SKIP_TRANSACTION procedure

Scope

Database

Enterprise Manager name

Skip Edit Properties

Note:
Enterprise Manager indirectly supports skipping a transaction using the Skip Edit Properties page.

See Also:
Oracle Database PL/SQL Packages and Types Reference

9.2.24 LsbyDSkipCfgPr

Deletes an existing skip specification from SQL Apply. It reverses or removes the actions of the LsbyASkipCfgPr property by finding the record, matching all the parameters, and removing the record from the system table. The match must be exact, and multiple skip actions can be removed only by a matching number of unskip actions. You cannot remove multiple skip actions by using wildcard characters as a value to this property.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category

Description

Datatype

String

Valid Values

A valid set of arguments to the DBMS_LOGSTDBY.UNSKIP procedure

Broker Default

Empty string

Imported?

No

Parameter Class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.UNSKIP procedure

Scope

Database

Enterprise Manager name

Remove Skip Table Entries

See Also:
Oracle Database PL/SQL Packages and Types Reference

9.2.25 LsbyDSkipErrorCfgPr

Deletes an existing skip error specification from SQL Apply. It reverses or removes the actions of the LsbyASkipErrorCfgPr property by finding the record, matching all of the parameters and removing the record from the system table. The match must be exact, and multiple skip actions can be removed only by a matching number of unskip actions. You cannot remove multiple skip actions by using wildcard characters as a value to this property.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category

Description

Datatype

String

Valid values

A valid set of arguments to the DBMS_LOGSTDBY.UNSKIP_ERROR procedure. The string must contain comma separators between the arguments.

Broker default

Empty string

Imported?

No

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.UNSKIP_ERROR procedure

Scope

Database

Enterprise Manager name

Remove Skip Table Entries

See Also:
Oracle Database PL/SQL Packages and Types Reference

9.2.26 LsbyDSkipTxnCfgPr

Reverses or removes the actions of the LsbyASkipTxnCfgPr property. The transaction IDs must match exactly, and multiple skip transaction actions can be removed only by a matching number of unskip transaction actions. You cannot remove multiple skip transaction actions by using wildcard characters as a value to this property.

Specifying a value for this property has no effect and will be ignored if management of the standby database is disabled.

Category

Description

Datatype

String

Valid values

A valid set of arguments to the DBMS_LOGSTDBY.UNSKIP_TRANSACTION procedure

Broker default

Empty string

Imported?

No

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.UNSKIP_TRANSACTION procedure

Scope

Database

Enterprise Manager name

Not applicable

See Also:
Oracle Database PL/SQL Packages and Types Reference

9.2.27 LsbyMaxEventsRecorded

Specifies the number of events that will be stored in the DBA_LOGSTDBY_EVENTS table, which stores logical standby event information.

Category

Description

Datatype

Integer

Valid values

>=0

Broker default

0

Imported?

Yes, from the MAX_EVENTS_RECORDED row of SYSTEM.LOGSTDBY$PARAMETERS

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED') and the DBMS_LOGSTDBY.APPLY_UNSET('MAX_EVENTS_RECORDED') procedures

Scope

Database

Enterprise Manager name

Max Events Recorded

9.2.28 LsbyMaxSga

Specifies the number of megabytes for the allocation of SQL Apply cache in the system global area (SGA). If the value is 0, SQL Apply uses one quarter of the value set for the SHARED_POOL_SIZE initialization parameter.

Category

Description

Datatype

Integer

Valid values

>=0

Broker default

0

Imported?

Yes, from the MAX_SGA row of SYSTEM.LOGSTDBY$PARAMETERS

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.APPLY_SET('MAX_SGA') and the DBMS_LOGSTDBY.APPLY_UNSET('MAX_SGA') procedures

Scope

Instance

Enterprise Manager name

Max SGA (MB)

9.2.29 LsbyMaxServers

Specifies the number of parallel query servers specifically reserved for SQL Apply. If the value is 0, SQL Apply uses all available parallel query servers to read the log files and apply changes.

Category

Description

Datatype

Integer

Valid values

>=0

Broker default

0

Imported?

Yes, from the MAX_SERVERS row of SYSTEM.LOGSTDBY$PARAMETERS

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS') and the DBMS_LOGSTDBY.APPLY_UNSET('MAX_SERVERS') procedures

Scope

Instance

Enterprise Manager name

Max Servers

9.2.30 LsbyRecordAppliedDdl

Controls whether or not DDL statements that were applied to the logical standby database are recorded in the DBA_LOGSTDBY_EVENTS table. Specify one of the following values:

- TRUE: DDL statements applied to the logical standby database are recorded in the DBA_LOGSTDBY_EVENTS table. This is the default setting.

- FALSE: Applied DDL statements are not recorded.

Category

Description

Datatype

String

Valid values

TRUE or FALSE

Broker default

TRUE

Imported?

Yes, from the RECORD_APPLIED_DDL row of SYSTEM.LOGSTDBY$PARAMETERS

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.APPLY_SET('RECORD_APPLIED_DDL') and the DBMS_LOGSTDBY.APPLY_UNSET('RECORD_APPLIED_DDL') procedures

Scope

Database

Enterprise Manager name

Record Applied DDL

9.2.31 LsbyRecordSkipDdl

Controls whether or not skipped DDL statements are recorded in the DBA_LOGSTDBY_EVENTS table. Specify one of the following values:

- TRUE: Skipped DDL statements are recorded in the DBA_LOGSTDBY_EVENTS table. This is the default setting.

- FALSE: Skipped DDL statements are not recorded in the DBA_LOGSTDBY_EVENTS table.

Category

Description

Datatype

String

Valid values

TRUE or FALSE

Broker default

TRUE

Imported?

Yes, from the RECORD_SKIP_DDL row of SYSTEM.LOGSTDBY$PARAMETERS

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.APPLY_SET('RECORD_SKIP_DDL') and the DBMS_LOGSTDBY.APPLY_UNSET('RECORD_SKIP_DDL') procedures

Scope

Database

Enterprise Manager name

Record Skip DDL

9.2.32 LsbyRecordSkipErrors

Controls whether or not skipped errors (as described by the DBMS_LOGSTDBY.SKIP_ERROR procedure) are recorded in the DBA_LOGSTDBY_EVENTS table. Specify one of the following values:

- TRUE: Skipped errors are recorded in the DBA_LOGSTDBY_EVENTS table.

- FALSE: Skipped errors are not recorded in the DBA_LOGSTDBY_EVENTS table.

Category

Description

Datatype

String

Valid values

TRUE or FALSE

Broker default

TRUE

Imported?

Yes, from the RECORD_SKIP_ERRORS row of SYSTEM.LOGSTDBY$PARAMETERS

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to

DBMS_LOGSTDBY.APPLY_SET('RECORD_SKIP_ERRORS') and the DBMS_LOGSTDBY.APPLY_UNSET('RECORD_SKIP_ERRORS') procedures

Scope

Database

Enterprise Manager name

Record Skip Errors

9.2.33 LsbyTxnConsistency

Controls the level of transaction consistency maintained between the primary and standby databases. Specify one of the following values:

- FULL: Transactions are applied to the logical standby database in the exact order in which they were committed on the primary database. This option may affect performance.

- READ_ONLY: Transactions are committed out of order (which provides better performance). SQL SELECT statements return read-consistent results. This is particularly beneficial when the logical standby database is being used to generate reports.

Note:
DML statements involving standby tables are not allowed in this mode.

- NONE: Transactions are committed out of order and no attempt is made to provide read-consistent results. This results in the best performance of the three modes. If applications reading the logical standby database make no assumptions about transaction order, this option works well.

Category

Description

Datatype

String

Valid values

FULL or READ_ONLY or NONE

Broker default

FULL

Imported?

Yes, from the PRESERVE_COMMIT_ORDER row of SYSTEM.LOGSTDBY$PARAMETERS

Parameter class

Not applicable

Role

Standby

Standby type

Logical

Corresponds to ...

DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER') and the DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER') procedures

Scope

Database

Enterprise Manager name

Transaction Consistency Level

9.2.34 MaxConnections

Specifies how the archiver (ARCn) processes on the primary database coordinate when sending redo data to standby databases. If the MaxConnections property is set to a nonzero value, redo transport services use multiple network connections to transmit redo data using the archiver process (ARCn).

Category

Description

Datatype

Integer

Valid values

>=0

Broker default

0

Imported?

Yes, from the MAX_CONNECTIONS column of the V$ARCHIVE_DEST view for the primary database.

Parameter class

Dynamic

Role

Standby

Standby type

Physical and logical

Corresponds to ...

- LOG_ARCHIVE_MAX_PROCESSES and PARALLEL_MAX_SERVERS initialization parametersFoot 1

- MAX_CONNECTIONS attribute for the LOG_ARCHIVE_DEST_n initialization parameter of the primary database

- MAX_CONNECTIONS column of the V$ARCHIVE_DEST view of the primary database

Footnote 1 The LOG_ARCHIVE_MAX_PROCESSES and PARALLEL_MAX_SERVERS initialization parameters affect the actual number of ARCn processes used by an instance. See Oracle Data Guard Concepts and Administration for more information.

9.2.35 MaxFailure

Specifies the maximum number of contiguous archiving failures before the redo transport services stop trying to transport archived redo log files to the standby database. A value of zero indicates that an unlimited number of failures are allowed.

Category

Description

Datatype

Integer

Valid values

>=0

Broker default

0

Imported?

Yes, from the MAX_FAILURE column of V$ARCHIVE_DEST view of the primary database

Parameter class

Dynamic

Role

StandbyFoot 1

Standby type

Physical and logical

Corresponds to ...

- MAX_FAILURE attribute for the LOG_ARCHIVE_DEST_n initialization parameter of the primary database

- MAX_FAILURE column of the V$ARCHIVE_DEST view of the primary database

Scope

Database

Enterprise Manager name

Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_n value of the primary database.

9.2.36 NetTimeout

Specifies the number of seconds the LGWR waits for Oracle Net Services to respond to a LGWR request. It is used to bypass the long connection timeout in TCP. This property is only used when the LogXptMode property of the same database is set to SYNC or ASYNC.

Category

Description

Datatype

Integer

Valid values

0, 15 to 1200

Broker default

180

Imported?

Yes, from the NET_TIMEOUT column of V$ARCHIVE_DEST view of the primary database

Parameter class

Dynamic

Role

StandbyFoot 1

Standby type

Physical and logical

Corresponds to ...

- NET_TIMEOUT attribute of the LOG_ARCHIVE_DEST_n initialization parameter of the primary database

- NET_TIMEOUT column of V$ARCHIVE_DEST view of the primary database

Scope

Database

Enterprise Manager name

Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_n value of the primary database.

9.2.37 PreferredApplyInstance

Indicates that a particular instance is the preferred choice for serving log apply services. It is only used when the database is a standby RAC database. The value could be an empty string (default) which means the broker chooses the apply instance.

Category

Description

Datatype

String

Valid Values

The instance name (SID) or empty string

Broker Default

Empty string

Imported?

No

Parameter Class

Not applicable

Role

Standby

Standby Type

Physical and logical

Corresponds to

Not applicable

Scope

Database

Enterprise Manager name

Apply Instance

See Also:
Section 4.5.7 for more information

9.2.38 ReopenSecs

Specifies the minimum number of seconds before the archiver process (ARCn, foreground, or log writer process) should try again to access a previously failed destination.

Category

Description

Datatype

Integer

Valid values

>=0 seconds

Broker default

300

Imported?

Yes, from the REOPEN_SECS column of V$ARCHIVE_DEST view of the primary database

Parameter class

Dynamic

Role

StandbyFoot 1

Standby type

Physical and logical

Corresponds to ...

- REOPEN attribute for the LOG_ARCHIVE_DEST_n initialization parameter of the primary database

- REOPEN_SECS column of the V$ARCHIVE_DEST view of the primary database

Scope

Database

Enterprise Manager name

Not applicable

Footnote 1 Although this property is set for the standby database, it is indirectly related to the redo transport services for the primary database. The broker propagates the setting you specify on the standby database to the corresponding attributes of the LOG_ARCHIVE_DEST_n value of the primary database.

9.2.39 SidName

Specifies the SID of the instance. The property can only be updated when broker management of the database is disabled. You should only update the value when the SID is changed, in which case you need to disable broker management of the database, update the SidName property to match with the new SID, and reenable broker management of the database.

Note:
If the value of the SidName property does not match the actual value of the SID, broker management of the database cannot be enabled.

Category

Description

Datatype

String

Valid values

SID of the instance

Broker default

Not applicable

Imported?

Yes

Parameter class

Not applicable

Role

Primary and standby

Standby type

Physical or logical

Corresponds to ...

INSTANCE_NAME column of the V$INSTANCE view

Scope

Instance

Enterprise Manager name

Not applicable

9.2.40 StandbyArchiveLocation

Specifies the location of archived redo log files arriving from a primary database. Oracle recommends that you always explicitly set the value (if flash recovery area is not in use).

Category

Description

Datatype

String

Valid values

Nonempty file specification of the location of archived redo log files on the standby database

Broker default

dgsby_db_unique_name

Imported?

Yes, from the DESTINATION column of the V$ARCHIVE_DEST fixed view of the standby database where the destination is a local destination and where the VALID_FOR attribute is compatible with the string (STANDBY_ROLE, STANDBY_LOGFILE); if no such destination exists, import is from the STANDBY_ARCHIVE_DEST initialization parameter

Parameter class

Dynamic

Role

Standby

Standby type

Physical or logical

Corresponds to ...

- LOCATION attribute of the LOG_ARCHIVE_DEST_n initialization parameter of the standby database with VALID_FOR compatible with (STANDBY_ROLE, STANDBY_LOGFILE)

- DESTINATION column of the V$ARCHIVE_DEST view of the standby database

Scope

Instance

Enterprise Manager name

Standby Archive Location

Note:
On a logical standby database, Oracle recommends the LOCATION attribute of the LOG_ARCHIVE_DEST_n initialization parameter for the local destination be different from the value of StandbyArchiveLocation property.

9.2.41 StandbyFileManagement

Affects how the add datafile operation on the primary database is applied on the standby database. If this property is set to AUTO, in conjunction with valid settings in the DbFileNameConvert property, a corresponding new datafile is automatically created on the standby database. The location of this new standby datafile is determined by the value of the DbFileNameConvert property.

If this property is set to MANUAL, you have to create the correct new datafile on the standby database manually.

Category

Description

Datatype

String

Valid values

AUTO or MANUAL

Broker default

AUTO

Imported?

Yes, from the STANDBY_FILE_MANAGEMENT initialization parameter

Parameter class

Dynamic

Role

Standby

Standby type

Physical or logical

Corresponds to ...

STANDBY_FILE_MANAGEMENT initialization parameter

Scope

Database

Enterprise Manager name

Not applicable

10 Troubleshooting Data Guard

This chapter describes various errors and how to solve them. This chapter contains the following topics:

- Section 10.1, "Sources of Diagnostic Information"

- Section 10.2, "General Problems and Solutions"

- Section 10.3, "Troubleshooting Problems During a Switchover Operation"

- Section 10.4, "Troubleshooting Problems During a Failover Operation"

- Section 10.5, "Troubleshooting Problems with the Observer"

10.1 Sources of Diagnostic Information

The Data Guard broker provides information about its activities in several forms:

- Database status information (see Section 4.7)

- Oracle alert log files

The broker records key information in the alert log file for each database. You can check the alert log files for such information when troubleshooting Data Guard.

- Data Guard "broker log" files

For each database in a broker configuration, the broker DMON process records important behavior and status information in a "broker log" file, useful in diagnosing Data Guard failures.

For example, the broker log files for all instances in a RAC are named as follows in a UNIX environment:

$ORACLE_HOME/rdbms/log/drc*.log

10.2 General Problems and Solutions

This section describes general problems and solutions. This section contains the following topics:

- ORA-16596: Object Not Part of the Data Guard Broker Configuration

- Redo Accumulating on the Primary Is Not Sent to Some Standby Databases

- Many Log Files Are Received on a Standby Database But Not Applied

- The Primary Database is Flashed Back

10.2.1 ORA-16596: Object Not Part of the Data Guard Broker Configuration

A request was issued to the broker, but the database instance through which you have connected is no longer a part of the broker configuration. You may see this error when the broker monitor (DMON) fails to locate a broker configuration profile for the database upon which it is running.

Solution Reconnect to the configuration through another database instance. Confirm that the value of the DB_UNIQUE_NAME initialization parameter for the database and the database object name in the broker configuration are identical.

This problem can also occur if you attempt to enable a configuration, but the broker configuration file for one of its databases was accidentally removed or is outdated. In this case, remove the database from the broker configuration, manually delete the configuration file for that standby database (not for the primary database), and try again to enable the configuration. After the configuration is enabled, run the Add Standby Database wizard and choose the Add existing standby database option to create a new database profile for the previously deleted standby database.

10.2.2 Redo Accumulating on the Primary Is Not Sent to Some Standby Databases

By viewing the Log File Details page in Enterprise Manager, you have determined that log files are accumulating on the primary database and are not being archived to some of the standby databases in the broker configuration.

Solution To narrow down the problem, do the following:

- Verify that the state of the primary database is ONLINE (not LOG-TRANSPORT-OFF).

- Verify that the value of the LogShipping property of the standby database in question is ON.

- Check the status of the redo transport services on the primary database using the LogXptStatus monitorable property. If redo transport services have an error, then use the error message to determine further checking and resolution action. For example:

- If the error indicates the standby database is not available, you need to restart the standby database.

- If the error indicates no listener, you need to restart the listener.

- If the error indicates the standby database has no local destination, you need to set up a standby location to store archived redo log files from the primary database.

10.2.3 Many Log Files Are Received on a Standby Database But Not Applied

By viewing the Performance page or Log File Details page in Enterprise Manager, you have determined that the standby database accumulates too many log files without applying them.

Solution There are many possible reasons why archived redo log files might not be applied to the standby database. Investigate why the log files are building up and rule out the valid reasons.

If the current status of the standby database is not normal:

- Determine whether or not the log apply services might be unexpectedly offline. See the ORA-16766 (for physical standby databases) or ORA-16768 (for logical standby databases) problem and solution statement for more help.

- If this is a logical standby database, check to see if a failed transaction has occurred.

- If you want to suppress the error while you investigate the problem, you can temporarily disable broker management of the database.

See Also:
Chapter 8 for additional information about disabling the database using the DGMGRL command-line interface

If the current status of the standby database is normal:

- Verify the state of the standby database is online (not in the LOG-APPLY-OFF, OFFLINE, or READ-ONLY states).

- Verify the state of the primary database is online (not in the LOG-TRANSPORT-OFF state).

- See Also:
Chapter 9 for additional information about the LogShipping property

- Check to see if log files are building up because the value of the DelayMins property is set too large. (Log apply services will delay applying the archived redo log files on the standby database for the number of minutes specified.)

See Also:
Chapter 9 for additional information about the DelayMins property

- If you cannot see any errors, compare the archive rate to the apply rate on the Performance page in Enterprise Manager to see if the apply rate is lower than the archive rate.

10.2.4 The Request Timed Out or Enterprise Manager Performance Is Sluggish

If the broker requests are not completing within the normal timeout parameters, try the following actions to solve the problem:

1. Verify the network is operating appropriately.

2. Try to ping all of the nodes in the configuration.

3. Try reconnecting through another database to retry the operation.

4. Run the VERIFY command from the configuration to see which broker is busy. The output from the VERIFY command should show why (or at least which) broker is not able to process the requests.

10.2.5 The Primary Database is Flashed Back

If the primary database is flashed back, the standby databases in the configuration must be also be flashed back or reenabled to be viable targets for switchovers or failovers. The broker will report errors for the standby databases if the primary database has been flashed back.

For more information about restoring the viability of a standby database that was disabled by the broker, see Section 5.4.3.

10.3 Troubleshooting Problems During a Switchover Operation

If the switchover fails due to problems with the configuration, the broker reports any problems it encounters in the alert log files or in the broker log files (see Section 10.1). In general, you can choose another database for the switchover or restore the configuration to its pre-switchover state and then retry the switchover. The following subsections describe how to recover from the most common problems.

Problems Transitioning the Primary Database to the Standby Role

If the error status indicates a problem when transitioning the original primary database to the standby role (including stopping redo transport services and starting log apply services), use these general guidelines to recover:

1. Disable the configuration using DGMGRL.

Note:
You can enable or disable the configuration using DGMGRL. You cannot disable the configuration using Enterprise Manager. You can enable the configuration using Enterprise Manager if it was previously disabled using DGMGRL.

2. Investigate the error message returned by the broker to find the source of the problem on the primary database and correct it. Oracle Enterprise Manager provides an Alert Log Content link for viewing alert log file information. You may also examine the contents of the broker log file for the primary database.

3. Reenable the configuration to refresh and restore the databases to their original roles and states.

4. Perform the switchover again.

Problems Transitioning the Standby Database to the Primary Role

If the error status indicates that a problem occurred when transitioning the target standby database to the primary role (including stopping log apply services and starting redo transport services), use these general guidelines to restore to the pre-switchover state.

If fast-start failover is enabled, the broker does not allow failover to any standby database except to the target standby database. In addition, failover to the target standby database is allowed only under certain conditions:

- The observer is running

- The value of the FS_FAILOVER_STATUS column in the V$DATABASE view on the target standby database is either READY or SUSPENDED.

See Also:
Section 5.5.2.1, "What Happens When Fast-Start Failover and the Observer Are Running?"

Step 1   Analyze and correct the detected failure.

1. Disable the configuration using DGMGRL.

Note:
You can enable or disable the configuration using DGMGRL. You cannot disable the configuration using the Enterprise Manager. You can enable the configuration using Enterprise Manager if it was previously disabled using DGMGRL.

2. Investigate the error messages returned by the broker to find the source of the problem on the standby database and correct it. Examine the alert log file information and the contents of the broker log file for the target standby database.

Step 2   Convert back to a primary database.

The original primary database was already converted to a standby database by the time this stage of the switchover is reached. The database must be converted back to being a primary database as follows:

1. Ensure the original primary database is at least mounted. A restart may be necessary:

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT

2. Execute the following SQL*Plus command to convert the database back to running in the primary database role:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

3. Restart the database if necessary. The database is now in its former role as a primary database.

Additional steps may be needed to allow any logical standby databases in the configuration to accept and apply redo logs from this primary database. See Oracle Data Guard Concepts and Administration for these steps.

Step 3   Finish the recovery.

1. Reenable the configuration.

2. Perform the switchover operation again.

Additional Problems that May Occur During a Switchover Operation

Problem: The switchover fails due to problems with redo transport services.

Solution:

1. Verify the state and status of the standby database by viewing its information on the Data Guard Overview page.

See Also:
Chapter 6 for additional information about the Data Guard Overview page

2. Run the Verify operation after the switchover completes to examine the alert log file of the new primary database and to verify the status of the configuration.

See Also:
Section 6.8.1 for additional information about verifying the configuration

Problem: The switchover may fail during verification checks done by Data Guard broker (for example, redo transport services might return errors on a database that is involved in the switchover).

Solution: Choose another database for the switchover or fix the problem by transporting the archived redo log files.

10.4 Troubleshooting Problems During a Failover Operation

Although it is possible for a failover to stop, it is unlikely. If an error occurs, it is likely to happen when the standby database is transitioning to the primary role. If the error status indicates that this problem occurred, use these general guidelines to fix the problem:

1. Investigate the error information provided by the broker to find the source of the problem and correct it.

2. Perform the failover again.

The following problems may occur during a failover operation:

Problem: The primary database is still running. Enterprise Manager tries to detect if the primary database is still running. However, if the primary database is still running and the Enterprise Manager cannot detect that it is running, the failover will not be successful.

Solution: If the primary database is still running but can no longer function as a primary database, shut it down and retry the failover.

10.5 Troubleshooting Problems with the Observer

The observer continuously monitors the fast-start failover environment to ensure the primary database is available. Installing and starting the observer is an integral part of enabling fast-start failover. The following sections describe techniques for troubleshooting the observer:

- Problems Starting the Observer

- Problems Because the Observer Has Stopped

- Capturing Observer Actions in the Observer Log File

10.5.1 Problems Starting the Observer

Only one observer can be associated with the broker configuration at any given time. If you attempt to start a second observer, one of the following errors is returned:

ORA-16647: could not start more than one observer
DGM-16954: Unable to open and lock the Observer configuration file

Use the DGMGRL SHOW CONFIGURATION VERBOSE command to determine the location of the observer that is currently associated with the broker configuration.

DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxAvailability
Fast-Start Failover: ENABLED
Databases:
North_Sales - Primary database
DR_Sales    - Physical standby database
- Fast-Start Failover target

Fast-Start Failover
Threshold: 45 seconds
Observer:  observer.foo.com

Current status for "DRSolution":
SUCCESS

10.5.2 Problems Because the Observer Has Stopped

If the observer host machine crashes, the broker configuration is no longer observed and fast-start failover is no longer possible. In this case, you may have to move the observer to a new host if the original host machine cannot be repaired in a timely fashion. To move the observer, you must stop the first observer and then start a new observer on another host.

1. Issue the DGMGRL STOP OBSERVER command to sever the link between the original observer and the broker configuration:

DGMGRL> STOP OBSERVER;
Done.

2. Issue the DGMGRL SHOW CONFIGURATION VERBOSE and the SHOW DATABASE command to verify that the configuration is no longer being observed:

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration
Name:                DRSolution
Enabled:             YES
Protection Mode:     MaxAvailability
Fast-Start Failover: ENABLED
Databases:
North_Sales - Primary database
DRSales     - Physical standby database
- Fast-Start Failover target

Fast-Start Failover
Threshold: 45 seconds
Observer:  (none)

Current status for "The SUPER cluster":
Warning: ORA-16608: one or more databases have warnings

DGMGRL> SHOW DATABASE 'North_Sales';
Database
Name:            North_Sales
Role:            PRIMARY
Enabled:         YES
Intended State:  ONLINE
Instance(s):
sales1
Current status for "North_Sales":
Error: ORA-16658: unobserved Fast-Start Failover configuration

3. Note that you do not need to issue the DGMGRL SHOW commands to verify that the observer has actually stopped. Successful completion of the DGMGRL STOP OBSERVER command will allow a new observer to become associated with the configuration.
Now, you may start the new observer. After the observer is started, it prints its failover and reinstatement actions to the console in which it was started. For example:

DGMGRL> START OBSERVER;
Observer started

14:41:23.95  Thursday, May 26, 2005
Initiating fast-start failover to database "DRSales"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "DRSales"
14:41:38.62  Thursday, May 26, 2005

14:42:15.43  Thursday, May 26, 2005
Initiating reinstatement for database "North_Sales"...
Reinstating database "North_Sales", please wait...
Operation requires shutdown of instance "sales1" on database "North_Sales"
Shutting down instance "sales1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "sales1" on database "North_Sales"
Starting instance "sales1"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "North_Sales" ...
Reinstatement of database "North_Sales" succeeded
14:43:23.71  Thursday, May 26, 2005

10.5.3 Capturing Observer Actions in the Observer Log File

You can use the DGMGRL -logfile option to start the observer, so that all of the troubleshooting actions performed in Section 10.5.1 can be captured in a file. For example:

% dgmgrl -logfile observer.log / "start observer"

All the observer output is then recorded in a file named observer.log in the current working directory where you issued the DGMGRL command.

A Changed and Deprecated Features

This appendix details the Data Guard broker features that were changed, deprecated or made obsolete. This appendix provides the following sections:

- Section A.1, "Changed Features"

- Section A.2, "Deprecated and Obsolete Features"

A.1 Changed Features

This section contains information about Data Guard broker features that were changed.

A.1.1 General Features That Changed

The following sections list features that have changed:

- Changed Features in Release 10.2

- Changed Features in Release 10.1

A.1.1.1 Changed Features in Release 10.2

- Changed failover behavior

After failover to a logical standby database, the broker disables all standby databases in the configuration that were not directly involved in the failover. The disabled databases must be reenabled before they can serve as standby to the new primary database. Previously, failover to a logical standby database resulted in the broker disabling only physical standby databases.

- Changed DelayMins property behavior

When the DelayMins property is set to 0, log apply services apply redo data to the standby database as soon as it is received, including using real-time apply if the standby database is configured with standby redo logs.

If Flashback Database is enabled on the primary database, you can reinstate the old primary database after a failover, avoiding having to perform the manual steps required to reenable a database. In addition, when failing over to a physical standby database, other physical standby databases that were not directly involved in the failover can be reinstated (if they had Flashback Database enabled prior to the failover).

Additionally, if you specified the DelayMins and RealTimeApply properties on your release 10.1 database, the delay behavior might change unexpectedly. This is due to the RealTimeApply property being deprecated in release 10.2

For example, if your release 10.1 database had the DelayMins property set to a nonzero value and the RealTimeApply property set to YES, the delay setting was ignored because the real-time apply setting overrides any delay settings. However, because in release 10.2 the RealTimeApply property is deprecated, the release 10.2 database will no longer be affected by the RealTimeApply property and unexpectedly delay the application of redo according to the time specified by the DelayMins property.

A.1.1.2 Changed Features in Release 10.1

- The concept of a graceful failover was renamed to complete failover while forced failover was renamed to immediate failover.

See Also:
Chapter 8 for information about the Oracle Database 10g Data Guard broker FAILOVER command

- The concept of a primary site was changed to a primary database and standby site was changed to standby database. The former site object of a broker configuration was eliminated for Oracle Data Guard.

- The Enterprise Manager default behavior has been reversed when removing parts of a broker configuration. Enterprise Manager now clears the archive destination parameter upon removal of a database from the broker configuration, or clears all of the parameters upon removal of the entire configuration. Enterprise Manager still provides the option of preserving these values as was done by default in previous releases.

A.1.2 Changed Properties

The following sections list properties that have changed:

- Changed Properties in Release 10.2

- Changed Properties in Release 10.1

A.1.2.1 Changed Properties in Release 10.2

The following properties were changed in release 10.2:

Table A-1 Changed Properties in Release 10.2

Property Name

Description of Change

ApplyInstanceTimeout

The default value has changed from 120 seconds to 0 seconds.

ApplyParallel (configurable property)

- New default value is AUTO

- Can no longer specify the number of processes to use for Redo Apply

DelayMins

Using this property is the preferred method for delaying the application of redo data to a standby database. If you set DelayMins property to 0:

- Any previously configured DelayMins setting will be ignored.

- The standby database will apply redo data as soon as possible, including using real-time apply if the standby database is configured with standby redo logs.

If you have more than one physical standby database in the configuration, Oracle recommends using Flashback Database after a failing over to a physical standby databases. You can use Flashback Database to reinstate any physical standby databases that were disabled but were not the target of the failover.

LogArchiveMaxProcesses

Range of valid values is now from 1 to 30 (was from 1 to 10)

LsbyTxnConsistency

Now imports the value of PRESERVE_COMMIT_ORDER from SYSTEM.LOGSTDBY$PARAMETERS instead of TRANSACTION_CONSISTENCY

NetTimeout

The default value has changed from 30 seconds to 180 seconds.

A.1.2.2 Changed Properties in Release 10.1

Table A-2 shows properties that changed in release 10.1:

Table A-2 Changed Properties in Release 10.1

Property Name

Description of Change

AsyncBlocks (configurable property)

- New default value is 61,440

Note: This property has been deprecated in release 10.2.

InconsistentLogXptProps (monitorable property)

- STANDBY_NAME column replaces STANDBY_SITE_NAME.

- INSTANCE_NAME is a new column.

- MEMORY_VALUE column replaces DATABASE_VALUE.

- BROKER_VALUE column replaces METADATA_VALUE.

InconsistentProperties (monitorable property)

- INSTANCE_NAME is a new column.

- MEMORY_VALUE column replaces DATABASE_VALUE.

- BROKER_VALUE column replaces METADATA_VALUE.

LogXptMode (configurable property)

New default values are:

- ASYNC for standby databases with standby redo log files

- ARCH for standby databases without standby redo log files

LogXptStatus (monitorable property)

- Output was changed to a table format.

ParallelApply (configurable property)

- Allows input values AUTO and NO.

RecvQEntries (monitorable property)

- Replaces SbyLogQueue property.

- THREAD is a new column.

- FIRST_CHANGE# is a new column.

- NEXT_CHANGE# is a new column.

- SIZE is a new column.

SendQEntries (monitorable property)

- THREAD is a new column.

- STANDBY_NAME column replaces SITE_NAME.

- FIRST_CHANGE# is a new column.

- NEXT_CHANGE# is a new column.

- SIZE is a new column.

See Also:
Chapter 9, "Database Properties"

A.1.3 Changed State Names in Release 10.1

Table A-3 shows the state names that changed in Release 10.1:

Table A-3 State Name Changes

Database Type

State Name Prior to Oracle Database 10g

New State Name as of Oracle Database 10g

Primary

READ-WRITE

LOG-TRANSPORT-OFF

Primary

READ-WRITE-XPTON

ONLINE

Physical standby

PHYSICAL-APPLY-READY

LOG-APPLY-OFF

Physical standby

PHYSICAL-APPLY-ON

ONLINE

Logical standby

LOGICAL-APPLY-READY

LOG-APPLY-OFF

Logical standby

LOGICAL-APPLY-ON

ONLINE

See Also:
Section 4.2, "Database States"

A.1.4 Changed DGMGRL Features in Release 10.2

Data Guard command-line interface (DGMGRL) commands that changed in Oracle Database 10g (10.2) include:

- FAILOVER

- EDIT CONFIGURATION

- EDIT DATABASE

- SHOW CONFIGURATION

See Also:
Chapter 8, "Data Guard Command-Line Interface Reference"

A.1.5 Changed DGMGRL Features in Release 10.1

When removing a standby database from the broker configuration, DGMGRL provides you with a choice about removing the standby destination from the primary database so that log files are no longer transported to that standby database. The default for this choice in Oracle Database 10g (starting in Release 10.1) is to remove that destination. This is a reversal of the default (and only) behavior as it was implemented in the Oracle9i DGMGRL command-line interface.

A.1.6 Changed Enterprise Manager Features in Release 10.1

This section contains information about Enterprise Manager features that changed in release 10.1.

- You cannot disable broker management of the broker configuration from within Enterprise Manager as had been allowed in previous releases. You can only do this from the command-line interface.

- In this release of Oracle Database 10g, the Test Application feature will not be available.

- View Log does not view alert or broker log files.

- When removing a standby database from the broker configuration, Enterprise Manager presents you with a choice about removing the standby destination from the primary database so that log files are no longer transported to that standby database. The default for this choice in Oracle Database 10g is to remove that destination. This is a reversal of the default as it was implemented in Oracle9i Data Guard Manager.

A.2 Deprecated and Obsolete Features

The following sections list features that have been deprecated or made obsolete:

- Deprecated and Obsolete Features in Release 10.2

- Deprecated and Obsolete Features in Release 10.1

A.2.1 Deprecated and Obsolete Features in Release 10.2

This section contains information about Data Guard broker features that were deprecated or are obsolete.

A.2.1.1 Deprecated and Obsolete Properties in Release 10.2

Table A-4 Deprecated Properties

Deprecated Property

Replacement Property (if any)

ApplyNext

No replacement.

ApplyNoDelay

Set the DelayMins property to zero (0).

AsyncBlocks

None. Specifying the number of blocks is no longer necessary. The transport mode is determined automatically by redo transport services, based on the protection mode defined for the Data Guard configuration.

RealTimeApply

Set the DelayMins property to zero (0).

A.2.2 Deprecated and Obsolete Features in Release 10.1

This section contains information about Data Guard broker features that were deprecated or are obsolete.

- The concept of a site object is obsolete.

- The concept of a database resource object is obsolete.

Both of these objects were replaced by database objects.

Also, the following sections list properties, DGMGRL commands, and Enterprise Manager features deprecated or made obsolete in release 10.1

A.2.2.1 Deprecated and Obsolete Properties in Release 10.1

Table A-5 shows properties that were deprecated and if there is a replacement property.

Table A-5 Deprecated Properties

Deprecated Property

Replacement Property (if any)

Alternate

No replacement

StandbyArchiveDest

StandbyArchiveLocation

SbyLogQueue

RecvQEntries

See Also:
Chapter 9, "Database Properties" for information about the properties that replaced deprecated properties.

A.2.2.2 Deprecated and Obsolete DGMGRL Commands in Release 10.1

Table A-6 shows DGMGRL commands or keywords that were deprecated or made obsolete, and indicates if there is a replacement command or keyword.

Note:
Existing Oracle9i command-line scripts are supported in Oracle Database 10g for non-RAC databases. Oracle recommends upgrading your scripts to replace deprecated commands and keywords with their Oracle Database 10g replacements.

Table A-6 Deprecated Commands or Keywords

Deprecated Command or Keyword

Replacement Command or Keyword

ALTER CONFIGURATION (protection mode)

EDIT CONFIGURATION (protection mode)

ALTER CONFIGURATION (state)

No replacement

ALTER RESOURCE (property)

EDIT DATABASE (property)

ALTER RESOURCE (state)

EDIT DATABASE (state)

ALTER SITE (AUTO PFILE)

EDIT INSTANCE (AUTO PFILE)

ALTER SITE (state)

No replacement

CREATE CONFIGURATION

PRIMARY SITE IS site-name

RESOURCE IS resource-name

HOSTNAME IS host-name

INSTANCE NAME IS instance-name

SERVICE NAME IS net-service-name

SITE IS MAINTAINED AS standby-type

CREATE CONFIGURATION

PRIMARY DATABASE IS database-name

CONNECT IDENTIFIER IS connect-identifier

CREATE SITE

No replacement

DISABLE RESOURCE

DISABLE DATABASE

DISABLE SITE

No replacement

ENABLE RESOURCE

ENABLE DATABASE

ENABLE SITE

No replacement

FAILOVER TO site-name

GRACEFUL

FORCED

FAILOVER TO database-name

IMMEDIATE

REMOVE SITE

REMOVE DATABASE

SHOW CONFIGURATION VERBOSE property-name

SHOW CONFIGURATION

SHOW DEPENDENCY TREE

No replacement

SHOW LOG

No replacement

SHOW RESOURCE

SHOW DATABASE

SHOW SITE

No replacement

SWITCHOVER TO site-name

SWITCHOVER TO database-name

See Also:
Chapter 8, "Data Guard Command-Line Interface Reference" for information about the commands that replaced deprecated commands.

A.2.2.3 Obsolete Enterprise Manager Feature in Release 10.1

The Add Site wizard is obsolete and has been replaced by the Add Standby Database wizard. Use the Add Standby Database wizard to create a broker configuration and to create new or add existing standby databases to the broker configuration.

B Data Guard Broker Upgrading and Downgrading

This appendix guides you through the process of upgrading or downgrading the Oracle databases and Oracle Enterprise Manager in a broker configuration. It contains the following topics:

- Upgrade from Release 9.0.n to Release 10.n

- Upgrade from Release 9.2.0 to Release 10.n

- Upgrade from Release 10.1 to Release 10.2

- Downgrade from Release 10.2

See Also:
Chapter 2 for information about installing Oracle Data Guard

B.1 Upgrade from Release 9.0.n to Release 10.n

If you are currently running an Oracle Data Guard release 9.0.n configuration, you must upgrade to Oracle Database release 10.n and re-create the broker configuration, as follows:

1. Delete (remove) the release 9.0.n broker configuration using the same release of either Enterprise Manager or DGMGRL. For example, the DGMGRL REMOVE CONFIGURATION command can be used.

2. Upgrade the database software to Oracle Database release 10.n. See the Oracle installation documentation that is appropriate for your operating system.

3. If you are using Oracle Enterprise Manager and Data Guard Manager release 9.0.n, you must upgrade to Oracle Enterprise Manager release 10.n to manage a broker configuration running Oracle Data Guard release 10.n:

- Data Guard Manager release 9.0.n is not compatible with Oracle Data Guard release 10.n.

- Enterprise Manager release 10.n is not compatible with Oracle Data Guard release 9.0.n. You will receive an error message stating that the Oracle database is too old.

4. If you are using DGMGRL release 9.0.n, you must upgrade to Data Guard command-line interface release 10.n:

- DGMGRL release 9.0.n is not compatible with Oracle Data Guard release 10.n.

Note:
Existing Oracle9i command-line scripts are supported in Oracle Database 10g for non-RAC databases. See Appendix A for information about deprecated commands.

- DGMGRL release 10.n is not compatible with Oracle Data Guard release 9.0.n.

Note:
Oracle Database 10g command-line scripts are not supported in Oracle9i.

5. Invoke the Enterprise Manager or DGMGRL, and re-create the broker configuration.

See Also:
See Oracle Database Upgrade Guide if you are upgrading from Oracle8i Data Guard to Oracle Data Guard

B.2 Upgrade from Release 9.2.0 to Release 10.n

If you are currently running an Oracle Data Guard release 9.2.0 configuration, you must upgrade to Oracle Database release 10.n, and re-create the broker configuration, as follows:

1. Delete (remove) the release 9.2.0 broker configuration using Data Guard Manager or DGMGRL release 9.2.0. For example, the DGMGRL REMOVE CONFIGURATION command can be used.

2. If using DGMGRL, clear the LOG_ARCHIVE_DEST_n initialization parameter settings by using the ALTER SYSTEM SET LOG_ARCHIVE_DEST_n=" " SQL*Plus command.

3. Upgrade the database software to Oracle release 10.n. See the Oracle Database installation documentation that is appropriate for your operating system.

4. If you are using Oracle Enterprise Manager and Data Guard Manager release 9.2.0, you must upgrade to Oracle Enterprise Manager release 10.n to manage a broker configuration running Oracle Data Guard release 10.n. Data Guard Manager release 9.2.0 is not compatible with Oracle Data Guard release 10.n.

5. If you are using DGMGRL release 9.2.0, you must upgrade to Data Guard command-line interface release 10.n:

- DGMGRL release 9.2.0 is not compatible with Oracle Data Guard release 10.n.

Note:
Existing Oracle9i command-line scripts are supported in Oracle Database 10.n for non-RAC databases. See Appendix A for information about deprecated commands.

- DGMGRL release 10.n is not compatible with Oracle Data Guard release 9.2.0.

Note:
Oracle Database 10.n command-line scripts are not supported in Oracle9i.

6. Invoke Enterprise Manager or the DGMGRL command-line interface, and re-create the broker configuration.

B.3 Upgrade from Release 10.1 to Release 10.2

If you are currently running an Oracle Data Guard release 10.1 configuration, you can upgrade the database software to Oracle release 10.2 using the Oracle Database installation documentation that is appropriate for your operating system.

Step 1   Shut down the 10.1 Data Guard broker.

Disable the broker's management of the configuration and then stop the broker. For example:

1. Issue the following DGMGRL command to disable the broker's active management of the databases in the Data Guard configuration:

DGMGRL> DISABLE CONFIGURATION;

2. Issue the following SQL*Plus statement to stop the broker:

SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;

Step 2   Make a copy of the current broker configuration files.

Make a copy of the current broker configuration files, as indicated by the following initialization parameters: DG_BROKER_CONFIG_FILE1 and DG_BROKER_CONFIG_FILE2.

Step 3   Upgrade the Oracle Database software to release 10.2.

For step-by-step upgrade instructions, see the Oracle Database installation documentation that is appropriate for your operating system.

To upgrade Oracle Enterprise Manager Grid Control or DGMGRL, consider the following recommendations:

- If you are running Oracle Enterprise Manager Grid Control release 10.1, you can use it to manage a broker configuration running Oracle Data Guard release 10.2. However, Oracle recommends that you upgrade to Oracle Enterprise Manager Grid Control release 10.2 to take advantage of the new features and enhancements (described in the What's New preface of this book).

- If you are using DGMGRL release 10.1, you must upgrade to Data Guard command-line interface release 10.2 to manage a broker configuration running Oracle Data Guard release 10.2.

Note:
Existing release 10.1 DGMGRL command-line scripts are supported by the DGMGRL command-line interface available in release 10.1.
Release 10.2 DGMGRL command-line scripts are not guaranteed to be supported by Oracle Database release 10.1.

Step 4   Start the broker.

After the upgrade, start the release 10.2 Data Guard Broker. For example:

1. Issue the following SQL*Plus statements to start the broker:

SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE;

2. Issue the following DGMGRL command to enable the broker's active management of the databases in the Data Guard configuration:

DGMGRL> ENABLE CONFIGURATION

The first time the release 10.2 broker starts, it will detect the existence of the release 10.1 broker configuration files and automatically upgrade them to include any new properties that were introduced in release 10.2 (for example, the fast-start failover properties). This automatic conversion is transparent, permanent, and occurs only once.

See Also:
Appendix A, "Changed and Deprecated Features"

B.4 Downgrade from Release 10.2

If you have upgraded to release 10.2 and want to downgrade to your prior release, you must downgrade the database release and re-create the broker configuration as follows:

1. Delete (remove) the release 10.2 broker configuration using Enterprise Manager or DGMGRL release 10.2. For example, the DGMGRL REMOVE CONFIGURATION command can be used.

2. Downgrade the Oracle Database software to the prior Oracle release. See the Oracle Database documentation that is appropriate for your operating system.

3. You may downgrade the Data Guard broker to release 10.1, as follows:

- If you are using Enterprise Manager, you may continue to use Enterprise Manager release 10.2 to manage your 10.1 broker configuration.

- If you are confident that you made no changes to your broker configuration after upgrading to release 10.2, you may copy the broker configuration files that you created during the upgrade procedure (described in Section B.3). Then, invoke Enterprise Manager or the DGMGRL command-line interface and re-enable the broker configuration as it existed at the time you made that copy.

- Alternatively, you may invoke Enterprise Manager or the DGMGRL command-line interface to re-create the broker configuration.

4. You may downgrade the Data Guard broker to Oracle release 9.2.0, as follows:

- If you were using Enterprise Manager, you may continue to use the Oracle Enterprise Manager release 10.2 to manage your 9.2.0 broker configuration. You may also downgrade to the Data Guard Manager by re-installing Oracle Enterprise Manager release 9.2.0.

- Invoke Enterprise Manager, the Data Guard Manager, or the DGMGRL command-line interface and re-create the broker configuration.

5. You may downgrade to Oracle release 9.0.n, as follows:

- If you were using Enterprise Manager, you must downgrade to the Data Guard Manager by re-installing Oracle Enterprise Manager release 9.0.n. The Oracle Database 10g Data Guard GUI is not compatible with Oracle Data Guard release 9.0.n.

- Invoke the Data Guard Manager or the DGMGRL command-line interface and re-create the broker configuration.

Glossary

apply instance

In an Oracle Real Application Clusters (RAC) databases environment, the apply instance is the one instance applying archived redo log files to a standby database.

broker

A distributed management framework that automates and simplifies most of the complex operations required to create, control, and monitor a Data Guard configuration.

broker configuration

A logical grouping of the primary and standby databases (including redo transport services and log apply services) of a Data Guard configuration.

See also Data Guard configuration.

configuration object

A named collection of database objects. It is an abstraction of a Data Guard configuration.

database guard

The database guard controls whether or not modifications can be made to the tables in a logical standby database. You can override the database guard to allow changes to the logical standby database by executing the ALTER SESSION [ENABLE | DISABLE] GUARD statement.

database object

A named object that corresponds to a primary or standby database in a Data Guard configuration. The broker uses this object to manage and control the state of a single database and to associate properties with the database.

Data Guard command-line interface

The Data Guard command-line interface (DGMGRL) enables you to control and monitor a Data Guard configuration from the DGMGRL prompt or within scripts.

Data Guard configuration

A distributed computing system that prevents or minimizes losses due to unplanned events (for example, human errors, environmental disasters, or data corruption) as well as to planned downtime (such as for routine maintenance tasks).

See also broker configuration.

Data Guard environment

The physical configuration of the primary and standby databases. The environment depends on many factors, including the:

- Number of standby databases associated with a primary database

- Number of host systems used by the databases

- Directory structures of the machines used by the databases

- Network configuration

- Redo transport services

- Log apply services

The Data Guard environment can be managed manually by a DBA, automatically using Enterprise Manager or the Data Guard command-line interface (DGMGRL) or a combination of all of these.

default state

The initial runtime state in which the database object will run when you enable broker management of the configuration. The actual default state can vary depending on the role (primary or standby) in which the database is running.

See also intended state.

failover

Failover changes a standby database into the role of a primary database and disables the old primary database.

See also fast-start failover and manual failover.

fast-start failover

Enables a failover automatically when the primary database becomes unavailable. When fast-start failover is enabled, the broker determines if a failover is necessary and automatically, quickly, and reliably fails over to a designated, synchronized standby without requiring that you perform any manual steps to invoke the failover and with no loss of data.

See also manual failover.

instance

A named object; a database object is a collection of one or more named instances. The broker uses this object to manage and control the state of the database with which the instance is associated, and to associate instance-specific properties with this instance of the database.

intended state

The runtime state of a database object while it is enabled for management by the broker.

See also default state.

lights out computing

Refers to computing equipment or software whose operations are automated, requiring little to no intervention by human administrators.

The term "lights out" originated from when computing centers were located in one room and contained a number of servers that were kept under lock and key and in the dark. Under normal operation, the room was not not entered by human administrators, and all operations in the room were automated.

logical standby database

A logical standby database takes standard Oracle archived redo log files, transforms them back into SQL transactions, and then applies them to an open standby database. Although changes can be applied concurrently with end-user access, the tables being maintained through regenerated SQL transactions allow read-only access to users of the logical standby database. Because the database is open to allow application of reconstructed SQL transactions, it is physically different from the primary database. The database tables can have different indexes and physical characteristics from their primary database peers, but the tables must maintain logical consistency from an application access perspective, to fulfill their role as a standby data source.

manual failover

A failover that is initiated by the DBA who first determines a failover is necessary and then invokes one by clicking FAILOVER in Enterprise Manager or by issuing the DGMGRL FAILOVER command. The word manual is used to contrast this type of failover with a fast-start failover.

See also fast-start failover.

observer

A DGMGRL client that continuously monitors the primary and target standby databases, evaluates whether failover is necessary, and initiates a fast-start failover when conditions warrant.

physical standby database

A physical standby database is physically identical to the primary database. While the primary database is open and active, a physical standby database is either performing recovery (by applying online redo log files), or open for reporting access. A physical standby database can be queried (read-only mode) when not performing recovery while the primary database continues to archive redo logs.

primary database

A production database from which one or more standby databases is created and maintained. Every standby database is associated with one and only one primary database. A single primary database can, however, support multiple standby databases. The Data Guard broker monitor (DMON) maintains the master copy of the binary configuration file with the primary database, ensuring that each standby database's copy of the file is kept up to date as changes are made.

The broker refers to this database using the value in the DB_UNIQUE_NAME initialization parameter which is defined to be globally unique.

profiles

The description of a database object including its current state (on or off), properties, and current status (for example, its health). This description is maintained persistently by the broker in its binary configuration file.

read-only mode

A physical standby database mode that is initiated using the following SQL statement:

ALTER DATABASE OPEN READ ONLY;

The read-only mode enables you to query a physical standby database, but does not allow you to make changes to it. While in this mode, online redo log files are archived but are not applied until the physical standby database reenters Redo Apply mode.

Redo Apply

A physical standby database is kept synchronized with the primary database through Redo Apply, which recovers the redo data received from the primary database and applies the redo to the physical standby database.

SQL Apply

A logical standby database is kept synchronized with the primary database through SQL Apply, which transforms the data in the redo received from the primary database into SQL statements and then executes the SQL statements on the standby database.

standby database

A copy of a primary database created using a backup of your primary database. Standby databases are kept synchronized with the primary database by applying archived redo log files over time from the primary database to each standby database. The standby database can take over processing from the primary database, providing nearly continuous database availability. A standby database has its own server parameter file, control file, and datafiles. It also has a copy of the broker's configuration file, kept up to date at the direction of the DMON process running in the primary database instance.

The broker refers to a standby database by its globally unique name that is stored in its DB_UNIQUE_NAME initialization parameter.

See also logical standby database and physical standby database.

Index
A  B  C  D  E  F  G  H  I  L  M  N  O  P  Q  R  S  T  U  V  W

A

ADD DATABASE command, 8.2

Add Standby Database wizard

creating a broker configuration, 3.4, 6.2

creating a standby database, 6.2

definition, 1.5.1

introduction, 1.5.1

adding

an existing RAC standby database, 6.3

standby database to the broker configuration, 7.2

ALTER SYSTEM statement

starting the broker, 7.1

altering

properties

database, 7.7.1.1

states

database, 7.7.1.2, 7.7.1.3

AlternateLocation property, 9.2.1

setting log apply services, 4.4.3

application integration, 1.2 apply errors

managing, 4.5.5

apply instance, 4.5.7

failover, 4.5.7

of standby database, 4.2.1

PreferredApplyInstance property, 4.5.7.1

selecting, 4.5.7.1

ApplyInstanceTimeout property, 4.5.7.2, 9.2.2 ApplyParallel property, 4.5.2, 9.2.3 ARCH redo transport service, 4.4.1 architecture

Data Guard broker, 1.4

ARCHIVE_LAG_TARGET initialization parameter

setting in a broker configuration, 9.2.4

archived redo logs

destination and configuration parameters, 3.1

in a Data Guard configuration, 3.1

primary database setup, 2.2

ArchiveLagTarget property, 9.2.4 ASYNC redo transport service, 4.4.1 Automatic Storage Management (ASM)

creating a standby database that uses, 2.2

B

background processes

DMON, 1.6.1

banners

suppressing from DGMGRL command-line interface output, 8.1.1

before you perform a switchover, 5.3.1 before you use DGMGRL, 7.1 benefits

Data Guard broker, 1.2

high availability, 1.2

scalability, 1.2

with Real Application Clusters, 1.2

binary configuration file, 1.6.2 Binding property, 9.2.5 broker

components, 1.4

configuration, 1.1.1

Data Guard configuration file, 1.6.2

drc* log files, 10.1

installation, 2.2

introduction, 1.1.2

managing databases, 4.1

user interfaces, 1.5

broker configurations, 4.6.2.5

add an existing RAC standby database, 6.3

benefits, 1.2

changing roles, 3.4

components, 3.1

creating, 6.2, 7.2, 7.2, 8.2

Data Guard configuration file, 1.6.1

database objects, 1.3

database profiles, 1.3

disabling databases, 3.5, 8.2

effects of removing metadata from, 8.2

enabling, 7.4, 8.2

enabling databases, 3.4, 3.5, 7.4, 8.2

enabling fast-start failover, 8.2

health, 1.6.1, 3.6

instance objects, 1.3

life cycle, 3.4

management, 1.3, 1.5.1, 1.5.2, 1.6.2

monitoring, 6.8, 7.10

objects, 1.3

Oracle Net Services configuration, 1.2, 1.5.1

overview, 3.1

properties, 4.3

protection modes, 8.2

removing, 6.10.2

setting protection mode, 4.6.1

status modes, 3.6

supported, 1.3, 3.1, 3.1

using SHOW CONFIGURATION to verify fast-start failover, 7.6

verifying, 6.8.1

C

CFS

See cluster file system

changed features, A changing

properties

databases in a broker configuration, 3.4, 4.3.2

of a database in a broker configuration, 6.5.2

protection mode

of a database in a broker configuration, 6.5.3

roles

within the broker configuration, 3.4

states

databases in a broker configuration, 3.4, 4.2.1

of a standby database in a broker configuration, 6.5.1

of databases in a broker configuration, 7.7

See also editing cluster file system (CFS)

broker configuration files, 3.2.2.1

Cluster Ready Services (CRS), 1.2 command prompts

suppressing from DGMGRL command-line interface output, 8.1.1

command-line interface

See Data Guard command-line interface (DGMGRL)

COMPATIBLE initialization parameter

requirements for setting, 2.2

complete failover, 5.4.1, 8.2

reinstating disabled databases, 5.4.3.1

components

broker, 1.4

Data Guard configuration, 3.1

configurable properties, 4.3

AlternateLocation, 9.2.1

ApplyInstanceTimeout, 9.2.2

ApplyParallel, 9.2.3

ArchiveLagTarget, 9.2.4

Binding, 9.2.5

database, 4.3.2, 4.3.2, 9.2

DbFileNameConvert, 9.2.6

DelayMins, 9.2.7

Dependency, 9.2.8

FastStartFailoverTarget, 9.2.9

FastStartFailoverThreshold, 9.2.10

FastStartFailoverThreshold property, 8.2

HostName, 9.2.11

InitialConnectIdentifier, 9.2.12

LocalListenerAddress, 9.2.13

LogArchiveFormat, 9.2.14

LogArchiveMaxProcesses, 9.2.15

LogArchiveMinSucceedDest, 9.2.16

LogArchiveTrace, 9.2.17

LogFileNameConvert, 9.2.18

LogShipping, 9.2.19

LogXptMode, 9.2.20

LsbyASkipCfgPr, 9.2.21

LsbyASkipErrorCfgPr, 9.2.22

LsbyASkipTxnCfgPr, 9.2.23

LsbyDSkipCfgPr, 9.2.24

LsbyDSkipErrorCfgPr, 9.2.25

LsbyDSkipTxnCfgPr, 9.2.26

LsbyMaxEventsRecorded, 9.2.27

LsbyMaxServers, 9.2.29

LsbyMaxSga, 9.2.28

LsbyRecordAppliedDdl, 9.2.30

LsbyRecordSkipDdl, 9.2.31

LsbyRecordSkipErrors, 9.2.32

LsbyTxnConsistency, 9.2.33

managing redo transport services, 4.4

MaxConnections, 9.2.34

MaxFailure, 9.2.35

NetTimeout, 9.2.36

PreferredApplyInstance, 9.2.37

ReopenSecs, 9.2.38

SidName, 9.2.39

StandbyArchiveLocation, 9.2.40

StandbyFileManagement, 9.2.41

TopWaitEvents, 9.1.11

configuration files

fast-start failover configuration (fsfo.dat) file, 5.5.6.6

located on raw devices, 3.2.1

See Also Data Guard configuration file

CONNECT command, 7.2, 8.2 connecting

privileges required for Data Guard broker configurations, 8.1.3

starting the observer, 7.6

to the primary database, 7.2

to the standby database, 4.4.6

connection credentials

using Oracle Wallet, 7.6

controlling

available SGA memory, 4.5.3

transaction consistency level, 4.5.3

CREATE CONFIGURATION command, 7.2, 8.2 creating

a broker configuration, 6.2, 7.2, 7.2, 7.2, 8.2

with the Add Standby Database wizard, 3.4

a standby database, 3.4, 6.2, 6.2, 8.2

D

Data Guard

troubleshooting, 10

Data Guard broker

changed features, A

deprecated features, A

integration with Oracle Enterprise Manager, 6.1

See Alsobroker

Data Guard command-line interface

commands, 1.5.2

ENABLE FAST_START FAILOVER, 8.2

SET STATE, 4.5.7.1

DG_BROKER_START initialization parameter, 2.2 enabling a database, 7.4 introduction, 1.1.2, 1.5.2 Data Guard command-line interface (DGMGRL)

banners from output, 8.1.1

commands

ADD DATABASE, 8.2

CONNECT, 8.2

CREATE CONFIGURATION, 8.2

DISABLE CONFIGURATION, 8.2

DISABLE DATABASE, 8.2

DISABLE FAST_START FAILOVER, 5.5.4, 8.2

EDIT CONFIGURATION (property), 8.2

EDIT CONFIGURATION (protection mode), 8.2

EDIT DATABASE (property), 8.2

EDIT DATABASE (rename), 8.2

EDIT DATABASE (state), 8.2

EDIT INSTANCE (AUTO PFILE), 8.2

EDIT INSTANCE (property), 8.2

ENABLE CONFIGURATION, 8.2

ENABLE DATABASE, 8.2

EXIT, 8.2

FAILOVER, 7.9

HELP, 8.2

QUIT, 8.2

REMOVE CONFIGURATION, 8.2

REMOVE DATABASE, 8.2

REMOVE INSTANCE, 8.2

SHOW CONFIGURATION, 8.2

SHOW DATABASE, 8.2

SHOW INSTANCE, 8.2

SHUTDOWN, 8.2

STARTUP, 8.2

SWITCHOVER, 7.8, 8.2

creating

a standby database, 8.2

and adding a primary database, 8.2

creating a configuration, 7.2 DG_BROKER_START initialization parameter, 8.1.3 enabling the configuration, 7.4 FAILOVER command, 5.4.2 FSFO.DAT file creation, 8.2 monitoring broker configurations, 7.10 performing routine management tasks, 7.7 prerequisites, 7.1 setting critical database properties, 7.3 setting up standby redo log files, 4.6.1 single command mode, 8.1.1 starting, 7.2, 8.1 stopping, 8.2 string values, 8.1.3 summary of commands, 8.1.2 suppressing command prompts, 8.1.1 Data Guard configuration file

for a RAC database, 3.2.2

in a CFS area, 3.2.2.1

inconsistent values from server parameter file, 9.1.2

on a raw device, 3.2.2.3

relationship to DMON process, 1.6.1

renaming, 1.6.2

setting up, 3.2

Data Guard configurations

automated creation of, 1.2

background, 3.1

supported, 3.1

Data Guard Fast-Start Failover metrics

understanding, 6.9.1.1

Data Guard monitor (DMON), 1.6

in a broker configuration, 3.1

in a Data Guard configuration, 3.1

interaction with the Oracle database, 1.6.1

maintaining configuration data, 1.6.2

managing objects, 3.1, 3.4, 7.4

Oracle database background processes, 1.6.1

overview, 1.6.1

removing objects, 7.7.3

running on each location, 3.1

starting with the DG_BROKER_START parameter, 3.3

two-way network communication, 1.6.1

Data Guard Performance metric

understanding, 6.9.1.2

Data Guard Status metric

understanding, 6.9.1.3

data protection modes

See protection modes

database resources

monitoring, 1.2

databases

changing the state of, 7.7

connecting to, 7.2

creating and adding to a broker configuration, 1.5.1

dependencies, 4.2

disabling management of, 8.2

during

fast-start failover, 5.5

manual failover, 5.4

switchover, 5.3

enabling, 7.4 health, 4.7 installation for broker management, 2.2 monitorable database properties, 4.3.1, 9.1 network setup, 1.6.1, 2.2 objects, 1.3

definition, 1.3

in a broker configuration, 1.3

prerequisites for broker configurations, 2.2 properties, 1.5.1, 4.3.2, 9.2 property management, 1.6.3 reenabling after a role transition, 5.4.3 removing

from a broker configuration, 7.7.3

restarting

after fast-start failover, 5.5.8

after manual failover, 8.2

shutting down

effect on fast-start failover, 5.5.2.1, 5.5.2.3, 5.5.8

states, 4.2

dependencies, 4.2

transitions, 4.2.1

status, 4.7 DB_FILE_NAME_CONVERT initialization parameter

initialization parameters

setting DB_FILE_NAME_CONVERT in a broker configuration, 9.2.6

DB_ROLE_CHANGE system event, 5.1 DB_UNIQUE_NAME initialization parameter, 4.4.6 db_unique_name_DGMGRL static service name

registering, 2.2

db_unique_name_XPT static service name, 4.4.6 DBA_LOGSTDBY_EVENTS table

managing, 4.5.6

DbFileNameConvert property, 9.2.6 delaying

application of redo data with DelayMins property, 4.5.1

DelayMins property, 9.2.7

delaying log apply services, 4.5.1

Dependency property, 4.4.4, 9.2.8 deprecated features, A destinations

archived redo log file parameters, 3.1

viewing the LogXptStatus property, 9.1.3

DG_BROKER_CONFIG_FILEn file, 1.6.2, 3.2.2

in a CFS area, 3.2.2.1

on a raw device, 3.2.2.3

DG_BROKER_START initialization parameter, 2.1, 2.2, 7.1, 8.1.3 DGMGRL

See Data Guard command-line interface (DGMGRL)

DGMGRL commands

FAILOVER, 8.2

SWITCHOVER, 8.2

diagnostic information

sources, 10.1

diagrams of database state transitions, 4.2.1 DISABLE CONFIGURATION command, 8.2

example, 7.7.2.1

DISABLE DATABASE command, 8.2

example, 7.7.2.2

DISABLE FAST_START FAILOVER command, 5.5.4, 8.2 disabling

broker configuration, 7.7.2, 8.2

broker management of standby database, 8.2

databases, 3.5, 7.7.2.1, 7.7.2.2

fast-start failover, 5.5.4, 8.2

on a standby database, 5.5.4

See also each DISABLE command disaster protection

benefits, 1.2

displaying

configuration information, 8.2

help for DGMGRL commands, 8.2

help for Enterprise Manager, 6.1

properties, 4.3

distributed management framework, 1.1.2 DMON

See Data Guard monitor (DMON)

downgrading

Data Guard, B.4

Oracle Enterprise Manager, B.4

protection mode, 4.6.2.1

drc* log files

broker diagnostic information, 10.1

during reinstatement, 5.5.3

recording failed reinstatment, 5.5.7.3

E

EDIT CONFIGURATION (Property) command, 8.2

EDIT CONFIGURATION (protection mode) command, 8.2

EDIT DATABASE (property) command, 8.2

example, 7.7.1.1

EDIT DATABASE (rename) command, 8.2 EDIT DATABASE (state) command, 8.2

example, 7.7.1.2

EDIT INSTANCE (AUTO PFILE) command, 8.2 EDIT INSTANCE (property) command, 8.2 editing

configurable properties, 8.2

database instance, 8.2, 8.2

database name, 8.2

database properties, 8.2

database state, 8.2

protection modes, 8.2

effect of switchovers on, 5.3.3 e-mail

reporting events, 1.5.1

ENABLE CONFIGURATION command, 7.4, 8.2 ENABLE DATABASE command, 8.2 ENABLE FAST_START FAILOVER command, 8.2 enabling

broker configuration, 3.4, 7.4, 7.4, 7.4

databases in a broker configuration, 3.5

fast-start failover, 5.5.1, 5.5.2, 6.4

See also each ENABLE command

Enterprise Edition database

installation, 2.1

Enterprise Manager

adding an existing RAC standby database, 6.3

changing

database properties, 6.5.2

database protection mode, 6.5.3

database state, 6.5.1

creating

a configuration, 6.2

a standby database, 6.2

Fast-Start Failover wizard

disabling fast-start failover, 5.5.4

managing metrics, 6.9.2 monitoring

broker configurations, 6.8

configuration performance, 6.8.3

performing

fast-start failover, 6.4

manual failover, 6.7

routine maintenance, 6.5

switchover, 6.6

removing

broker configuration, 6.10.2

standby database, 6.10.1

starting, 6.1 using metrics, 6.9 verifying a broker configuration, 6.8.1 viewing log file details, 6.8.2 wizards

automate standby database creation, 1.1.2

error messages

ORA-16795, 5.4.3, 5.4.3

error status, 3.6 events

managing

in a logical standby database, 4.5.6

monitoring with Oracle Enterprise Manager, 1.1.2 Oracle Enterprise Manager, 1.2 reporting, 1.5.1 responding to, 1.2 EXIT command, 8.2

See also QUIT command

F

failover

database restarts and, 8.2

failing over to a standby database, 8.2

Oracle Enterprise Manager, 1.5.1

FAILOVER command, 7.9, 8.2

manual failover, 5.4.2

failovers

and FastStartFailoverTarget property, 7.6

benefits, 1.2

broker tasks, 5.4.2.1

choosing a target standby database, 5.2

complete, 5.4.2, 5.4.2.1

defined, 5.1

fast-start failover, 5.5.2.2

effect on data protection mode, 5.5.1

V$DATABASE, 5.5.3

immediate, 5.4.2.2 managing, 5

fast-start, 5.5

manual, 5.4

manual

complete option, 5.4.1

effect on data protection mode, 5.4.2

immediate option, 5.4.1

reenabling disabled databases after, 5.4.2.1, 5.4.3 scenario

fast-start failover, 6.4

manual failover, 6.7

starting manually, 5.4.2 to a RAC database, 5.4.2 troubleshooting, 10.4 using DGMGRL, 7.9 failures

observer, 5.5.6.3

primary database, 5.1

fast-start failover, 5.1

broken network connections, 5.5.2.1

conditions resulting in, 5.5.2.1

configuration information in the fsfo.dat file, 5.5.6.6

defined, 5.5

DGMGRL client as the observer, 1.5.2

disabling, 5.5.4, 5.5.4

to perform manual failover, 5.5.4

enabling, 5.5.2, 6.4, 8.2 instance failures, 5.5.2.1 monitoring by the observer, 5.5.2.1 observer monitoring, 5.5.2.1 observer overview, 5.5 offline data files, 5.5.2.1 performing manual failovers when enabled, 5.5.2.4 performing switchover when enabled, 5.5.2.4 querying V$DATABASE, 5.5.2.2 reinstating the former primary database, 5.5.7 requirements, 5.5.1 restarting databases after shut down, 5.5.8 setting the FastStartFailoverTarget property, 5.5.2, 5.5.2, 5.5.2, 7.6 setting the FastStartFailoverThreshold property, 5.5.2, 6.4 shutdown abort, 5.5.2.1, 5.5.2.3 shutting down databases, 5.5.8 starting the observer, 5.5.2 to RAC database instances, 5.5.2.1 unobserved, 5.5.6.3 using SHOW CONFIGURATION to verify, 7.6 using SHOW CONFIGURATION VERBOSE, 5.5.3 verifying the environment, 5.5.2 viewing failover configuration statistics, 5.5.3 FastStartFailoverTarget property, 9.2.9

setting, 5.5.2, 5.5.2, 5.5.2, 7.6

FastStartFailoverThreshold property, 9.2.10

conditions causing fast-start failover, 5.5.2.1

configurable property, 8.2

setting, 5.5.2, 6.4

files

naming the server parameter file, 1.6.3

Flashback Database

reinstating databases, 5.4.3.1

use after failover, 5.4.2.1

flashback logs

reinstating a failed primary database, 5.4.3.1

FORCE option

disabling fast-start failover, 5.5.4, 8.2

performing a manual failover, 5.5.4

FS_FAILOVER_OBSERVER_HOST column

of V$DATABASE view, 5.5.6.2

FS_FAILOVER_OBSERVER_PRESENT column

of V$DATABASE view, 5.5.6.2

FS_FAILOVER_STATUS column

of V$DATABASE view

failed reinstatement, 5.5.3

FSFO.DAT file

overview, 5.5.6.6

START OBSERVER command, 8.2

G

global service names

registering, 2.2

GLOBAL_DBNAME attribute

setting, 2.2

H

health check, 1.2

monitoring, 1.6.1, 1.6.1

on primary database, 4.7

on standby database, 4.7

revealed by configuration status, 3.6

StatusReport property, 4.7

HELP command, 8.2 high availability

benefits, 1.2

levels of data protection, 4.6, 9.2.20

LogXptMode property, 9.2.20

restoring after fast-start failover, 5.5.7

HostName property, 9.2.11

I

immediate failover, 5.4.1, 8.2

InconsistentProperties property, 9.1.2

increased scalability

benefits, 1.2

InitialConnectIdentifier property, 9.2.12 initialization parameters

COMPATIBLE, 2.2

database configurable properties, 4.3.2

DB_UNIQUE_NAME, 4.4.6

DG_BROKER_CONFIG_FILEn, 3.2.2

DG_BROKER_START, 2.2, 7.1

dynamic, 4.3.2

inconsistent, 9.1.2

INSTANCE_NAME, 4.4.6

LOCAL_LISTENER, 2.2, 4.4.6, 4.4.6

LOG_ARCHIVE_DEST_n, 4.4.5

static, 4.3.2

See also server parameter file, 2.2

installation

ARCHIVELOG mode setup, 2.2

Data Guard, 2.1

Oracle Enterprise Manager, 2.1

Oracle Instant Client, 2.1, 8.2

prerequisites, 2.2

INSTANCE_NAME initialization parameter, 4.4.6 instances

failures, 5.5.2.1

objects

in a broker configuration, 1.3

removing, 8.2 restarting during the course of broker operations, 2.2 shutting down, 8.2 starting, 8.2 intended state

configuration health check, 3.6

invoking

the Data Guard command-line interface, 7.2

L

life cycle of a broker configuration, 3.4

listener

address, 4.4.6

LISTENER.ORA file

registering global service names, 2.2

local listener

for RAC databases, 2.2

statically registering services with, 2.2

LOCAL_LISTENER initialization parameter, 2.2, 4.4.6, 4.4.6, 4.4.6, 9.2.13

for standby instances, 4.4.6

LocalListenerAddress property, 9.2.13 log apply services

and apply instance failover, 4.5.7, 4.5.7.2

and parallel apply, 4.5.2

apply instance, 4.5.7

configuring, 1.2, 1.5.1

Data Guard configuration, 3.1

delayed application of redo data, 4.5.1

delaying, 9.2.7

in a RAC database, 4.5.7

managing, 4.5

selecting the apply instance, 4.5.7.1

verifying, 1.2

log files

broker, 5.5.7.3

FSFO.DAT

creating, 8.2

viewing, 6.8.2 LOG_ARCHIVE_DEST_n initialization parameter

SERVICE attribute, 4.4.6

setting redo transport services, 4.4.5

setting the DELAY attribute, 9.2.7

setting the DEPENDENCY attribute, 9.2.8

setting the ENABLE and DEFER attributes, 9.2.19

setting the MANDATORY or OPTIONAL attributes, 9.2.5

LOG_ARCHIVE_FORMAT initialization parameter, 9.2.14 LOG_ARCHIVE_MAX_PROCESSES initialization parameter, 9.2.15 LOG_ARCHIVE_MIN_SUCCEED initialization parameter, 9.2.16 LOG_ARCHIVE_TRACE initialization parameter

setting LogArchiveTrace property, 9.2.17

LOG_FILE_NAME_CONVERT initialization parameter

setting LogFileNameConvert property, 9.2.18

LogArchiveFormat property, 9.2.14 LogArchiveMaxProcesses property, 9.2.15 LogArchiveMinSucceedDest property, 9.2.16 LogArchiveTrace property, 9.2.17 LogFileNameConvert property, 9.2.18 logical standby databases

and SQL Apply error handling, 4.5.5

and SQL Apply filters, 4.5.4

during switchovers, 5.3.3

managing events, 4.5.6

SQL Apply, 4.5.3

state transitions, 4.2.1

switchover to the primary role, 5.3

LogShipping property, 9.2.19 LOG-TRANSPORT-OFF state

LogShipping property setting, 9.2.19

LogXptMode property, 9.2.20 LogXptStatus property, 9.1.3 LsbyASkipCfgPr property, 9.2.21 LsbyASkipErrorCfgPr property, 4.5.5, 9.2.22 LsbyASkipTxnCfgPr property, 9.2.23 LsbyDSkipCfgPr property, 9.2.24 LsbyDSkipErrorCfgPr property, 4.5.5, 9.2.25 LsbyDSkipTxnCfgPr property, 9.2.26 LsbyFailedTxnInfo property, 9.1.4 LsbyMaxEventsRecorded property, 9.2.27 LsbyMaxServers property, 9.2.29 LsbyMaxSga property, 4.5.3, 9.2.28 LsbyParameters property, 9.1.5 LsbyRecordAppliedDdl property, 9.2.30 LsbyRecordSkipDdl property, 9.2.31 LsbyRecordSkipErrors property, 9.2.32 LsbySkipTable property, 9.1.6 LsbySkipTxnTable property, 9.1.7 LsbyTxnConsistency property, 4.5.3, 9.2.33

M

management

benefits, 1.2

model, 1.3

Oracle Enterprise Manager, 1.5.1

managing

a broker configuration, 3, 7

apply errors, 4.5.5

Data Guard metrics, 6.9.2

databases, 4

DBA_LOGSTDBY_EVENTS table, 4.5.6

events

in a logical standby database, 4.5.6

fast-start failover, 5.5 local operations, 1.1.2 log apply services, 4.5 manual failover, 5.4 objects in a broker configuration, 1.3 parallel apply in a physical standby database, 4.5.2 remote operations, 1.1.2 roles, 5

fast-start failover, 5.5

manual failover, 5.4

switchover, 5.3

switchover, 5.3 MANDATORY attribute

set with the Binding property, 9.2.5

manual failover, 1.2, 5.1

complete option, 5.4.1

effect on protection modes, 4.6.2.3

immediate option, 5.4.1

performing when fast-start failover is enabled, 5.5.2.4, 5.5.4

starting, 5.4.2

to a RAC database, 5.4.2

manual role changes

performing when fast-start failover is enabled, 5.5.2.4

MaxConnections property, 9.2.34 MaxFailure property, 9.2.35 maximize availability, 1.2, 3.4, 9.2.20 maximize data protection, 1.2, 3.4, 9.2.20 maximize performance, 1.2, 3.4, 9.2.20 maximum availability

data protection mode, 4.6.1

maximum performance

data protection mode, 4.6.1

maximum protection

data protection mode, 4.6.1

metrics

Data Guard Fast-Start Failover, 6.9.1.1

Data Guard Performance, 6.9.1.2

Data Guard Status, 6.9.1.3

managing, 6.9.2

using, 6.9

monitorable properties, 4.3

database, 4.3.1

InconsistentProperties, 9.1.2

LogXptStatus, 9.1.3, 9.1.3

LsbyFailedTxnInfo, 9.1.4, 9.1.4

LsbyParameters, 9.1.5

LsbySkipTable, 9.1.6

LsbySkipTxnTable, 9.1.7

RecvQEntries, 9.1.8

SendQEntries, 9.1.9

StatusReport, 9.1.10

monitoring

broker configurations, 1.6.1, 6.8, 7, 7.10

configuration performance, 6.8.3

local and remote databases, 1.2

observer

fast-start failover environment, 5.5.2.1

Oracle Enterprise Manager performance page, 3.4 through the command-line interface, 1.5.2

N

NetTimeout property, 9.2.36

networks

broken connections, 5.5.2.1

Data Guard configuration, 3.1

setting up files, 2.2

two-way communication, 1.6.1

normal status, 3.6

O

objects

broker configuration, 1.3, 3.1

disabling, 7.7.2

properties for databases, 1.6.3

relationship, 1.3

observer, 5.5

and FastStartFailoverThreshold property, 5.5.2, 6.4

connecting to the configuration, 7.6

connection to the local computer, 5.5.6.2

detecting

broken network connections, 5.5.2.1

database shutdown, 5.5.2.1, 5.5.2.3

instance failures, 5.5.2.1

offline data files, 5.5.2.1

failures, 5.5.6.3 finding host machine name, 5.5.6.2 installing Oracle Instant Client kit, 2.1, 8.2 lost connection, 5.5.6.3 maintaining fast-start failover configuration information, 5.5.6.6 monitoring, 5.5.2.1, 5.5.2.1 shutting down, 5.5.8 starting, 5.5.2 using Oracle Wallet for connection credentials, 7.6, 8.2, 8.2 offline data files

broken, 5.5.2.1

ONLINE state

setting LogShipping property, 9.2.19

operations

complete failover, 8.2

disable broker management

effect on protection modes, 4.6.2.4

downgrade

effect on protection modes, 4.6.2.1

effect on protection modes, 4.6.2 enable broker management

effect on protection modes, 4.6.2.4

failover, 7.9

troubleshooting, 10.4

fast-start failover scenario, 6.4 immediate failover, 8.2 manual failover

effect on protection modes, 4.6.2.3

manual failover scenario, 6.7 removing a database from the configuration

effect on protection modes, 4.6.2.5

upgrade

effect on protection modes, 4.6.2.1

OPTIONAL attribute

set with the Binding property, 9.2.5

ORA-16649 message, 5.5.2.2 ORA-16661 message

reinstating a database, 5.4.3, 5.4.3, 5.4.3.1

ORA-16795 message

re-creating a database, 5.4.3

Oracle Cluster Repository (OCR)

setting START_OPTIONS, 2.2

Oracle Clusterware

and instances of a RAC database, 1.2

integration with Data Guard broker, 1.2

recover failed instances, 1.2

Oracle Enterprise Manager, 1.5.1

Add Standby Database wizard, 1.5.1

database property pages, 1.5.1

downgrading, B.4

event management system, 1.2

integration, 1.5.1

integration with the Data Guard monitor, 1.5.1

introduction, 1.1.2, 1.4

making Oracle Net Services configuration changes, 1.2, 1.5.1

monitoring events, 1.1.2

Overview page, 1.5.1

performance tools and graphs, 1.5.1

setting up standby redo log files, 4.6.1

upgrading, B.1, B.2

wizards

creating standby databases, 1.5.1

Oracle Instant Client

installing, 2.1, 8.2

Oracle Managed Files (OMF)

creating a standby database that uses, 2.2

Oracle Net Services

configuration changes, 1.2, 1.5.1

installation prerequisites, 2.2

supported configuration, 3.1

two-way communication, 1.6.1

Oracle Universal Installer

installing Oracle Instant Client, 2.1, 8.2

Oracle Wallet

starting the observer, 8.2, 8.2

when starting the observer, 7.6

P

parallel apply

and log apply services, 4.5.2

managing in a physical standby database, 4.5.2

performance

Enterprise Manager tools, 6.8.3

Oracle Enterprise Manager tools, 1.5.1

Personal Edition database

installation, 2.1

physical standby databases

during switchovers, 5.3.3

managing parallel apply, 4.5.2

state transitions, 4.2.1

switchover to the primary role, 5.3

port numbers

setting nondefault, 2.2, 4.4.6

PreferredApplyInstance property, 4.5.7.1, 9.2.37 prerequisites

installation, 2.2

setting a nondefault port number, 2.2, 4.4.6

switchover, 5.3.1

primary database

ARCHIVELOG mode, 2.2

configuration, 3.1

connecting to, 7.2, 7.2

constructing a standby database, 3.4, 7.1

Data Guard configuration, 3.1

during failover, 1.5.1

during switchover, 5.3.3

failed

reenabling, 5.4.3

Flashback Database, 5.4.3.1 health check, 4.7 preparing for switchover, 5.3.1 reinstating

REINSTATEMENT command, 5.4.3.1

reinstating after a fast-start failover, 5.5.7 shutting down when fast-start failover is enabled, 5.5.8 standby redo log files on, 4.6.1 state transitions, 4.2.1 switching over to the standby role, 8.2 processes

DMON, 1.6.1

Oracle database, 1.6.1

properties, 4.3.2

AlternateLocation, 4.4.3

ApplyInstanceTimeout, 4.5.7.2

ApplyParallel, 4.5.2

configurable, 4.3, 8.2

database, 4.3

DelayMins, 4.5.1

Dependency, 4.4.4

LsbyASkipErrorCfgPr, 4.5.5

LsbyDSkipErrorCfgPr, 4.5.5

LsbyMaxSga, 4.5.3

LsbyTxnConsistency, 4.5.3

managing, 1.6.3

monitorable, 4.3

PreferredApplyInstance, 4.5.7.1

setting, 3.4, 6.5.2, 7.3

in server parameter file, 1.6.3, 2.2

StandbyArchiveLocation, 4.4.3 StatusReport, 4.7 property pages

configuring, 1.5.1

database, 1.5.1

protection modes

after a failover, 4.6.2.3, 5.4.2, 5.5.1

benefits, 1.2

configuration, 8.2

downgrading, 4.6.2.1

of a database

changing in a broker configuration, 6.5.3

redo transport services setup, 9.2.20 setting for a broker configuration, 4.6 updating, 3.4 upgrading, 4.6.2.1

Q

QUIT command, 8.2

See also EXIT command

R

RAC databases

during switchovers, 5.3.3

registering services with the local listener, 2.2

raw devices

and broker configuration files, 3.2.2.3

configuration files located on, 3.2.1

sizing, 3.2.2.3

Real Application Clusters

adding to a broker configuration, 6.3

and apply instance failover, 4.5.7.2

and log apply services, 4.5.7

and redo transport services, 4.4.7

and setting the apply instance, 4.5.7.1

availability of instances with Oracle Clusterware, 1.2

benefits, 1.2

Cluster Ready Services (CRS), 1.2

effect of switchover on databases, 5.3.3

failing over to a database in, 5.4.2

fast-start failover, 5.5.2.1

observer behavior in, 5.5.2.1

observer connection to instances, 5.5.6.2

setting START_OPTIONS in OCR, 2.2

RecvQEntries property, 9.1.8 Redo Apply, 3.1, 5.3.3 redo transport services

and connections to the standby database, 4.4.6

ARCH mode, 4.4.1, 9.2.20

ASYNC mode, 4.4.1, 9.2.20

configuring, 1.2, 1.5.1

data protection modes, 9.2.20

Data Guard configuration, 3.1 in a RAC environment, 4.4.7 LogShipping property, 9.2.19 managing, 4.4 SYNC mode, 4.4.1, 9.2.20 tuning, 4.4.5 turning off, 4.4.2 turning on, 4.4.2 verifying, 1.2 reenabling

a database after failover or switchover, 5.4.3

registering

db_unique_name_DGMGRL service name, 2.2

db_unique_name_XPT service name, 4.4.6

reinstatement, 5.5.7

disabled databases, 5.4.3.1, 5.4.3.1

failiure logged in broker drc* log files, 5.5.3

Flashback Database requirement, 5.4.3.1

flashback logs requirement, 5.4.3.1

how to, 5.4.3.1

logged in broker log files, 5.5.7.3

ORA-16661 message, 5.4.3, 5.4.3, 5.4.3.1

requires standby redo log files, 4.6.1

using DGMGRL

DGMGRL, 5.4.3.1

using Enterprise Manager, 5.4.3.1 REINSTATEMENT command, 5.4.3.1 relationship

objects in a broker configuration, 1.3

REMOVE CONFIGURATION command, 8.2

example, 7.7.3

REMOVE DATABASE command, 8.2 REMOVE INSTANCE command, 8.2 removing, 4.6.2.5

a standby database, 4.6.2.5

broker configurations, 4.6.2.5, 6.10.2

See each REMOVE command

standby databases, 6.10.1

ReopenSecs property, 9.2.38 requests

passing between sites, 1.6.1

requirements

for enabling fast-start failover, 5.5.1

restarting

databases

when fast-start failover is enabled, 5.5.8

instances, 2.2 role transitions

changing, 3.4

managing, 5

fast-start failover, 5.5

manual failover, 5.4

switchover, 5.3

reenabling databases after, 5.4.3, 5.4.3 writing triggers to manage tasks after, 5.1

S

scenarios

switchover, 6.6

scripts

using Data Guard command-line interface (DGMGRL), 8

selecting the apply instance, 4.5.7.1 SendQEntries property, 9.1.9 server parameter file

broker property management, 1.6.3, 2.2

filenames, 1.6.3

inconsistent values from Data Guard configuration file, 9.1.2

server-side software, 1.6 service names

registering

db_unique_name_DGMGRL, 2.2

db_unique_name_XPT, 4.4.6

SET STATE command

and setting the apply instance, 4.5.7.1

setting

a dependent standby database, 4.4.4

configuration protection mode, 4.6.1

database properties, 7.3

log apply services, 4.4.3

redo transport services, 4.4.5

SGA memory

and SQL Apply, 4.5.3

SHOW CONFIGURATION command, 7.2, 7.2, 7.4, 8.2

verifying fast-start failover configuration, 7.6

SHOW CONFIGURATION VERBOSE command

viewing fast-start failover statistics, 5.5.3

SHOW DATABASE command, 8.2 SHOW DATABASE VERBOSE command

displaying properties, 4.3

SHOW INSTANCE command, 8.2 showing

See each SHOW command

shutdown

FS_FAILOVER_OBSERVER_PRESENT view, 5.5.8

shutdown abort, 5.5.2.1

effect on fast-start failover, 5.5.2.3

SHUTDOWN command, 8.2 shutting down an Oracle instance, 8.2 SidName property, 9.2.39 single command mode

for Data Guard command-line interface, 8.1.1

SQL Apply, 3.1

and logical standby databases, 4.5.3

effect of switchovers on, 5.3.3

error handling

and logical standby databases, 4.5.5

filters

and logical standby databases, 4.5.4

standby databases

apply instance, 4.2.1

changing the state of, 6.5.1

choosing a target standby database, 5.2

constructing from backups, 3.4, 7.1

creating, 1.5.1, 6.2, 6.2

if primary database uses ASM or OMF, 2.2

Data Guard configuration, 3.1 DB_UNIQUE_NAME initialization parameter, 4.4.6 health check, 4.7 LOCAL_LISTENER initialization parameter, 4.4.6 managing connections, 4.4.6 not involved in a switchover, 5.3.3 reenabling after failover, 5.4.2.1 reinstating, 5.4.3.1 removing, 4.6.2.5, 6.10.1, 8.2 require standby redo log files, 4.6.1 shutting down when fast-start failover is enabled, 5.5.8 specifying the location of archived redo logs, 4.4.3 switching over to the primary role, 8.2 standby redo log files

setting up, 4.6.1

setting up with DGMGRL, 4.6.1

StandbyArchiveLocation property, 9.2.40

setting log apply services, 4.4.3

StandbyFileManagement property, 9.2.41 START OBSERVER command

fast-start failover configuration file (fsfo.dat), 5.5.6.6

START_OPTIONS

setting in the Oracle Cluster Repository (OCR), 2.2

starting

Data Guard command-line interface (DGMGRL), 7.2, 8.1

Data Guard monitor (DMON), 3.3

Data Guard Web pages in Enterprise Manager, 6.1

manual failover, 5.4.2

Oracle instance, 8.2

switchover, 5.3.2

the observer, 5.5.2

STARTUP command, 8.2 state transitions

effect on database states, 4.2.1

logical standby database, 4.2.1

physical standby database, 4.2.1

primary database, 4.2.1

states, 3.5

any type of database

OFFLINE, 4.2

changing, 3.4, 7.7 database, 4.2 database transitions, 4.2.1 logical standby database

LOG-APPLY-OFF, 4.2

ONLINE, 4.2

of a standby database

changing in a broker configuration, 6.5.1

physical standby database

LOG-APPLY-OFF, 4.2

ONLINE, 4.2

READ-ONLY, 4.2

primary database

LOG-TRANSPORT-OFF, 4.2

ONLINE, 4.2

static service name registration, 2.2, 4.4.6, 4.4.6 status

configuration, 3.6

health check on primary database, 4.7

health check on standby database, 4.7

health of the database, 4.7

intended state of a configuration, 3.6

using metrics, 6.9

status messages

ORA-16661, 5.4.3, 5.4.3

ORA-16795, 5.4.3

StatusReport property, 4.7, 9.1.10 string values

Data Guard command-line interface, 8.1.3

supported broker configuration, 1.3 SWITCHOVER command, 7.8, 8.2 switchovers

benefits, 1.2

broker tasks, 5.3.3

choosing a target standby database, 5.2

DGMGRL SWITCHOVER command, 7.8

effect on

database startup, 8.2

logical standby databases, 5.3.3

physical standby databases, 5.3.3

primary database, 5.3.3

protection modes, 4.6.2.2

RAC databases, 5.3.3

standby databases not involved in the switchover, 5.3.3

managing, 5, 5.3 overview, 5.1

Oracle Enterprise Manager, 1.5.1

performing when fast-start failover is enabled, 5.5.2.4 preparing the primary database, 5.3.1 prerequisites, 5.3.1 reenabling disabled standby databases, 5.4.3 reinstating a database after, 5.4.3 scenario

Oracle Enterprise Manager, 6.6

starting, 5.3.2 transitioning

a logical standby database to the primary role, 5.3

a physical standby database to the primary role, 5.3

troubleshooting, 10.3, 10.3 using the DGMGRL SWITCHOVER command, 8.2 SYNC redo transport mode, 4.4.1 SYSDBA privileges, 7.2

to connect to the database, 8.1.3

system events

writing triggers for use DB_ROLE_CHANGE, 5.1

T

target standby database

choosing, 5.2

disabling fast-start failover on, 5.5.4

setting with the FastStartFailoverTarget property, 5.5.2, 5.5.2, 7.6

TopWaitEvents property, 9.1.11 transaction consistency level

controlling, 4.5.3

troubleshooting

Data Guard, 10

diagnostics logged in broker drc* log files, 10.1

tuning

redo transport services, 4.4.5

two-way communication channel, 1.6.1

U

understanding metrics, 6.9.1

unobserved configuration, 5.5.6.3

updating configuration properties, 4.3

upgrading

Data Guard, B.1, B.2, B.3

Oracle Enterprise Manager, B.1, B.2

protection mode, 4.6.2.1

user interfaces

overview, 1.5

V

V$DATABASE view

fast-start failover columns, 5.5.2.2, 5.5.3

FS_FAILOVER_OBSERVER_HOST column, 5.5.6.2

FS_FAILOVER_OBSERVER_PRESENT column, 5.5.6.2

when shutting down databases, 5.5.8

verifying

fast-start failover environment, 5.5.2

viewing

fast-start failover statistics, 5.5.3

verifying

a broker configuration, 6.8.1

fast-start failover environment, 5.5.2

viewing

log file details, 6.8.2

property information about databases, 4.3.1, 9.1

W

warning status, 3.6

wizards

Add Standby Database, 1.5.1, 6.2

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2016, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

Private Alpha and Beta Draft Documentation Notice

If this document is in private preproduction status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your beta trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.