Sie sind auf Seite 1von 348

D17316GC11

Edition 1.1

January 2005

D40345

D17316GC11 Edition 1.1 January 2005 D40345 Oracle Database 10 g : Data Guard Administration Student Guide

Oracle Database 10g: Data Guard Administration

Student Guide

Authors

Donna Keesling Ric Van Dyke

Technical Contributors and Reviewers

Christopher Andrews Larry Baumann Tammy Bednar Harald van Breederode Mary Bryksa Bernhard de Cock Buning Larry Carpenter Sean Connolly Raymond Dutcher Mark Fuller Joel Goodman Raymond Guzman Ziemowit Jankowski Nitin Karkhanis Jiangbin Luo Ashish Ray Vivian Schupmann Jim Spiller S Matt Taylor Michael Verheij John Watson

Publisher

Nita Brozowski

Copyright © 2005, Oracle. All rights reserved.

This documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If this documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:

Restricted Rights Legend

Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software and shall be deemed to be Restricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988).

This material or any portion of it may not be copied in any form or by any means without the express prior written permission of Oracle Corporation. Any other copying is a violation of copyright law and may result in civil and/or criminal penalties.

If this documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with “Restricted Rights,” as defined in FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).

The information in this document is subject to change without notice. If you find any problems in the documentation, please report them in writing to Education Products, Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065. Oracle Corporation does not warrant that this document is error-free.

All references to Oracle and Oracle products are trademarks or registered trademarks of Oracle Corporation.

All other products or company names are used for identification purposes only, and may be trademarks of their respective owners.

Contents

Preface

1 Oracle Data Guard: Overview Objectives 1-2

Causes of Data Loss

Every System Faces Down Time

1-3

1-4

What Is Oracle Data Guard? Types of Standby Databases

What Is Oracle Data Guard? Types of Standby Databases

1-5

1-6

Oracle Data Guard Broker Framework

Types of Services

Role Transitions: Switchover and Failover

Data-Protection Modes

Benefits of Implementing Oracle Data Guard

Role of Data Guard in a High Availability Architecture

Oracle Data Guard and Real Application Clusters

Maximum Availability Architecture Summary 1-18

Practice 1: Overview

1-7

1-8

1-9

1-11

1-13

1-14

1-16

1-17

1-19

2 Understanding the Oracle Data Guard Architecture Objectives 2-2

Data Guard Operational Requirements: Hardware and Operating System 2-3

Data Guard Operational Requirements: Oracle Database Software

2-4

Oracle Data Guard: Architecture

2-6

Primary Database Flow

2-7

Standby Database Flow 2-8

 

Standby Redo Logs 2-9 Data Guard Redo Apply: Architecture 2-10 Data Guard SQL Apply: Architecture 2-12

 

SQL Apply Process: Architecture

2-13

Real-Time Apply

2-14

 

Setting the DB_UNIQUE_NAME Parameter

2-16

Specifying Role-Based Destinations

2-17

Combinations for VALID_FOR

2-19

Identifying Destination Settings 2-20 Standby Redo Log Configuration 2-21 Number of Standby Redo Logs 2-22 Using SQL to Add Standby Redo Logs 2-23 Using Enterprise Manager to Add Standby Redo Logs 2-24 Standby Database Modes 2-25 Summary 2-27 Practice 2-1: Overview (Architecture) 2-28

 

Practice

2-2: Overview (Installing the Oracle Management Agent)

2-29

Practice

2-3: Overview (Configuring Your Primary Database)

2-30

iii

3

Data Guard Broker and Enterprise Manager Objectives 3-2

Features of Data Guard Broker

3-3

Data Guard Broker: Components Data Guard Broker: Configurations

Data Guard Broker: Components Data Guard Broker: Configurations

3-4

3-5

Data Guard Broker: Management Model

Data Guard Broker: Architecture

3-7

3-6

Life Cycle of a Broker Configuration Data Guard Broker: Requirements Data Guard Broker and the SPFILE Data Guard Monitor: DMON Process

Configuration Data Guard Broker: Requirements Data Guard Broker and the SPFILE Data Guard Monitor: DMON Process
Configuration Data Guard Broker: Requirements Data Guard Broker and the SPFILE Data Guard Monitor: DMON Process
Configuration Data Guard Broker: Requirements Data Guard Broker and the SPFILE Data Guard Monitor: DMON Process

3-8

3-9

3-11

3-13

Data Guard Monitor: Configuration File Benefits of Using the Data Guard Broker

Data Guard Broker Interfaces

Using Oracle Enterprise Manager 10 g Grid Control

Data Guard Overview Page

3-14

3-15

3-17

3-20

3-19

Enterprise Manager Metrics and Alerts

3-21

Using Data Guard Metrics

3-22

Managing Data Guard Metrics

3-23

Benefits of Using Enterprise Manager

3-24

Using the Command-Line Interface of the Data Guard Broker Summary 3-27

3-25

4 Creating a Configuration with Enterprise Manager Objectives 4-2

Enabling FORCE LOGGING Mode

Using Enterprise Manager to Create a Broker Configuration

Creating a Configuration

Using the Add Standby Database Wizard

Step 1: Specify the Backup Type

Step 2: Specify the Backup Options

Step 3: Select the Oracle Home – Instance Name

Step 3: Select the Oracle Home – Oracle Home

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

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

Step 5: Specify Standby Database Configuration Parameters

Step 6: Review the Configuration Information

Standby Database Creation: Processing

Standby Database Creation: Progress

Standby Database Creation: Job Details

Verifying a Configuration

Reviewing Results of the Verify Operation

Creating Standby Redo Logs

Viewing the Data Guard Configuration Status

Viewing Data Guard Performance Summary 4-27

Practice 4: Overview

4-3

4-5

4-6

4-8

4-9

4-10

4-11

4-12

4-15

4-16

4-17

4-19

4-20

4-22

4-21

4-23

4-24

4-25

4-28

iv

4-13

4-14

5 Creating a Physical Standby Database by Using SQL Objectives 5-2 Steps to Create a Physical Standby Database 5-3 Preparing the Primary Database 5-4 Initialization Parameters on the Primary Database 5-5 LOG_ARCHIVE_CONFIG 5-6 LOG_ARCHIVE_DEST_ n 5-7 LOCATION and SERVICE Attributes 5-8 LOG_ARCHIVE_DEST_STATE_ n 5-9 Specifying Values for DB_FILE_NAME_CONVERT 5-10 Specifying Values for LOG_FILE_NAME_CONVERT 5-11 Specifying a Value for LOG_ARCHIVE_FORMAT 5-12 Specifying a Value for STANDBY_FILE_MANAGEMENT 5-13 ARCHIVE_LAG_TARGET 5-14 LOG_ARCHIVE_TRACE Parameter 5-15 LOG_ARCHIVE_TRACE 5-16 Backing Up the Primary Database by Using RMAN 5-17

Creating a Control File for the Standby Database 5-18 Copying Files to the Standby Database System 5-19 Oracle Managed Files (OMF) and Automatic Storage Management (ASM) 5-20

Initialization Parameters on the Standby

5-21

Specifying a Value for STANDBY_ARCHIVE_DEST

Setting Up the Environment to Support the Standby Database 5-23 Starting Up the Physical Standby Database 5-25 Additional Configuration Tasks 5-26 Special Note: Standby Database on Same System 5-27 Summary 5-28

5-22

6 Data Protection Modes and Log Transport Services Objectives 6-2

Data Protection Modes and Log Transport Modes Attributes of LOG_ARCHIVE_DEST_ n 6-4

Setting the Log Transport Mode

Data Protection Modes

Maximum Protection Maximum Availability Maximum Performance

Setting the Data Protection Mode

Setting the Data Protection Mode by Using the CLI

Setting the Protection Mode by Using SQL

Delaying the Application of Redo

Using Enterprise Manager to Delay the Application of Redo

Setting LOG_ARCHIVE_DEST_ n to Delay the Application of Redo

Using Flashback Database Instead of Apply Delay

Additional Attributes That Affect Log Transport Services ALTERNATE and NOALTERNATE Attributes 6-21

6-3

6-6

6-8

6-9

6-10

6-11

6-12

6-16

6-14

6-15

6-17

6-19

6-20

6-18

MAX_FAILURE and NOMAX_FAILURE Attributes

6-22

NET_TIMEOUT and NONET_TIMEOUT Attributes

6-23

REOPEN and NOREOPEN Attributes Summary 6-25

Practice 6: Overview

6-26

6-24

v

7

Data Guard SQL Apply Architecture Objectives 7-2

Benefits of Implementing a Logical Standby Database

Securing Your Logical Standby Database

Preparing to Create a Logical Standby Database

Unsupported Data Types

Unsupported Objects

Checking for Tables with Unsupported Data Types

Unsupported DDL Commands Ensuring Unique Row Identifiers

Adding a Disabled Primary Key RELY Constraint

Supplemental Logging

Enabling Supplemental Logging

Verifying Values of Initialization Parameters

Creating a Logical Standby Database with Enterprise Manager

Using the Add Standby Database Wizard

Step 1: Specifying the Backup Type

Step 2: Specifying the Backup Options

Step 3: Selecting the Oracle Home – Instance Name

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

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

Step 5: Specifying Standby Database Configuration Parameters

Step 6: Reviewing the Configuration Information

Standby Database Creation Processing

Resolving a Failed or Canceled Configuration Creation Summary 7-29

Practice 7: Overview

7-3

7-5

7-6

7-9

7-13

7-7

7-8

7-10

7-11

7-16

7-14

7-17

7-18

7-19

7-20

7-21

7-22

7-23

7-24

7-25

7-26

7-27

7-28

7-30

8 Creating a Logical Standby Database by Using SQL Objectives 8-2

Preparing to Create a Logical Standby Database

Creating a Logical Standby Database

Step 1: Create a Physical Standby Database

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

Step 3: Prepare to Transition to a Logical Standby Database

Step 4: Start the Logical Standby Database

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

Additional Configuration Tasks Summary 8-15

8-3

8-4

8-5

8-10

8-8

8-12

8-14

9 Switchover and Failover Objectives 9-2

Types of Roles in an Oracle Data Guard Configuration

Role Management Services

Role Transitions: Switchover and Failover

Role Transition Decision Tree Switchover 9-8

9-4

9-7

9-5

Switchover: Before

9-9

Switchover: After

9-10

9-3

vi

Standby Redo Logs and Switchovers

9-11

9-12

Performing a Switchover with Enterprise Manager

Performing a Switchover to a Physical Standby by Using SQL

Performing a Switchover to a Logical Standby by Using SQL Considerations When Performing a Switchover to a

Logical Standby Database

Preparing for a Switchover

9-13

9-23

Situations That Prevent a Switchover Failover 9-26

Failover Considerations

Performing a Failover with Enterprise Manager

9-25

9-27

9-28

9-16

9-18

Performing a Failover to a Physical Standby Database

9-31

Performing a Failover to a Logical Standby Database

9-32

Performing a Failover to a Physical Standby Database by Using SQL Performing a Failover to a Logical Standby Database by Using SQL

Activating a Standby Database

Using Flashback Database After Failover

Summary 9-42 Practice 9: Overview

9-38

9-39

9-43

10 Using Data Guard with RAC Objectives 10-2

Real Application Clusters and Data Guard

Configuration Considerations with RAC

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

Log Transport with RAC to RAC

10-3

10-4

10-8

10-6

10-7

9-33

9-36

Setting Up a Primary Database with RAC Setting Up a Standby Database with RAC

Setting Up a Primary Database with RAC Setting Up a Standby Database with RAC

10-9

10-10

Assigning Threads to Standby Redo Log Groups

Apply Instance Failover

Role Transitions with RAC Troubleshooting 10-15 Summary 10-17

10-12

10-14

10-11

11 Other Considerations for Oracle Data Guard Objectives 11-2

Offloading Backups to a Physical Standby

11-3

Backing Up a Physical Standby Database with RMAN

11-4

Backup and Recovery of a Logical Standby Database

11-6

Using Flashback Database and Real-Time Apply

Using Flashback Database After RESETLOGS

Enabling Redo Encryption

Cascaded Redo Log Destinations

Configuring Cascaded Redo Log Destinations: Physical Standby Configuring Cascaded Redo Log Destinations: Logical Standby

Role Transitions with Cascaded Redo Log Destinations Summary 11-17

11-7

11-8

11-10

11-11

11-16

vii

11-12

11-14

12 Workshop

Objectives

Workshop Premise

Workshop Flow

Workshop Scenarios

Summary

Workshop Steps

12-2

12-3

12-5

12-4

12-8

12-10

Appendix A: Practices and Solutions

Appendix B: Oracle Data Guard: History

Preface

Profile

Before You Begin This Course

Before you begin this course, you should have the following qualifications:

• Thorough knowledge of Oracle Database 10g

• Working experience with Oracle Database 10g and Oracle Enterprise Manager Grid Control

Prerequisites

Oracle Database 10g: Administration Workshop I (D17090GC10)

Oracle Database 10g: Administration Workshop II (D17092GC20)

Suggested: Oracle Enterprise Manager 10g Grid Control (D17244GC10)

How This Course Is Organized

Oracle Database 10g: Data Guard Administration is an instructor-led course featuring lectures and hands-on exercises. Online demonstrations and written practice sessions reinforce the concepts and skills introduced.

Preface - 3

Related Publications

Oracle Publications Title

Part Number

Oracle Database Administrator's Guide 10g Release 1 (10.1)

B10739-01

Oracle Database Concepts 10g Release 1 (10.1)

B10743-01

Oracle Database Performance Tuning Guide 10g Release 1 (10.1)

B10752-01

Oracle Database Reference 10g Release 1 (10.1)

B10755-01

Oracle Database SQL Reference 10g Release 1 (10.1)

B10759-01

Oracle Database Utilities 10g Release 1 (10.1)

B10825-01

Oracle Data Guard Broker 10g Release 1 (10.1)

B10822-01

Oracle Data Guard Concepts and Administration 10g Release 1 (10.1)

B10823-01

Additional Publications

• System release bulletins

• Installation and user’s guides

• International Oracle User’s Group (IOUG) articles

Oracle Magazine

Preface - 4

Oracle Data Guard: Overview Copyright © 2005, Oracle. All rights reserved.

Oracle Data Guard: Overview

Oracle Data Guard: Overview Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Objectives

After completing this lesson, you should be able to do the following:

Describe the factors that affect planned and unplanned down time

Describe the basic components of Oracle Data Guard

Explain the differences between physical and logical standby databases

Explain the benefits of creating a Data Guard environment

Explain the use of Data Guard in high availability architectures

• Explain the use of Data Guard in high availability architectures Copyright © 2005, Oracle. All

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration

1-2

Causes of Data Loss

Hardware & system errors

 

49%

Human errors

 

36%

 

Computer viruses

7%

 

Software corruption

4%

 

Natural disasters

3%

 

Source: Disaster Recovery Journal

Natural disasters 3%   Source: Disaster Recovery Journal Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10g: Data Guard Administration

1-3

Every System Faces Down Time

Storage

failure

Human

error

Corruption

Site

failure

Computer

failures

Data

failures

Unplanned

down time

Unplanned down time
Unplanned down time
Unplanned down time
Unplanned down time
Unplanned down time
Unplanned down time
Unplanned down time

Data

changes

System

changes

Planned

down time

Planned down time
Planned down time
Planned down time
Planned down time
down time Data changes System changes Planned down time Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Unplanned Versus Planned Down Time Every system faces both unplanned and planned down time. It is important to consider

causes of both unplanned and planned down time when designing a fault-tolerant, resilient infrastructure. Unplanned down time consists of the following:

Computer failures: Down time occurs when there is a power outage or a system crash.

Data failures: Data failure is the loss, damage, or corruption of critical enterprise data. Causes of data failure include:

- Storage failure: Disk crash or space limitations

- Human error: Down time occurs when someone inadvertently drops a table or the system administrator makes an error.

- Corruption: Caused by a faulty component in the I/O stack

- Site failure: Down time occurs when there is some sort of data corruption or natural disaster such as a flood, fire, or earthquake.

Planned down time includes routine operations, periodic maintenance, and new deployments. Planned down time includes the following:

Data changes: Table redefinition and index rebuild

System changes: Down time occurs during hardware and operating-system upgrades.

Oracle Database 10g: Data Guard Administration

1-4

What Is Oracle Data Guard?

Production

Standby

database

Redo transport

database

Oracle Net
Oracle Net

Database

Database

copy

database Redo transport database Oracle Net Database Database copy Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

What Is Oracle Data Guard? Oracle Data Guard is a management, monitoring, and automation software infrastructure that works with a production database and one or more standby databases to protect your data against failures, errors, and corruptions that might otherwise destroy your database. It protects critical data by providing facilities to automate the creation, management, and monitoring of the databases and other components in a Data Guard configuration. It automates the process of maintaining a copy of an Oracle production database (called a standby database) that can be used if the production database is taken offline for routine maintenance or becomes damaged.

In a Data Guard configuration, a production database is referred to as a primary database.

A standby database is a transactionally consistent copy of the primary database. Using a

backup copy of the primary database, you can create from one to nine standby databases. The standby databases, together with the primary database, make up a Data Guard configuration. Each standby database is associated with only one primary database.

Note: You can use the Cascaded Redo Log Destinations feature to incorporate more than nine standby databases in your configuration. Refer to the “Other Considerations for Oracle Data Guard” lesson for additional information on this feature.

Oracle Database 10g: Data Guard Administration

1-5

Types of Standby Databases

There are two types of standby databases:

Physical standby database

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

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

Logical standby database

Shares the same schema definition

Synchronized with the primary database by transforming the data in the redo received from the primary database into SQL statements and then executing the SQL statements

database into SQL statements and then executing the SQL statements Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

Types of Standby Databases Physical Standby Database

A physical standby database is physically identical to the primary database, with on-disk

database structures that are identical to the primary database on a block-for-block basis.

The physical standby database is updated by performing recovery using redo data that is received from the primary database. The physical standby database can be either recovering data or open for read-only reporting. Logical Standby Database

A logical standby database is logically identical to the primary database. The logical

standby database is kept synchronized with the primary database by transforming the data

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

SQL statements on the standby database. This is done with the use of LogMiner technology on the redo log information received from the primary database. The tables in a logical standby database can be used simultaneously for recovery and for other tasks such as reporting, summations, and queries.

For more information on LogMiner, refer to Oracle Database Utilities.

Oracle Database 10g: Data Guard Administration

1-6

Oracle Data Guard Broker Framework

Oracle Data Guard Broker Framework Oracle Management Server Repository Agent Primary database Data Guard broker

Oracle

Management

Server

Repository Agent Primary database Data Guard broker Enterprise Manager
Repository
Agent
Primary
database
Data
Guard
broker
Enterprise Manager
Agent Data Guard broker
Agent
Data
Guard
broker
Guard broker Enterprise Manager Agent Data Guard broker Standby database CLI management client Copyright © 2005,
Guard broker Enterprise Manager Agent Data Guard broker Standby database CLI management client Copyright © 2005,

Standby

database

Manager Agent Data Guard broker Standby database CLI management client Copyright © 2005, Oracle. All rights
Manager Agent Data Guard broker Standby database CLI management client Copyright © 2005, Oracle. All rights
Manager Agent Data Guard broker Standby database CLI management client Copyright © 2005, Oracle. All rights
Manager Agent Data Guard broker Standby database CLI management client Copyright © 2005, Oracle. All rights
CLI management client
CLI management client

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10g: Data Guard Administration

1-7

Types of Services

There are three types of services provided with Data Guard:

Log transport services

Log apply services

Redo Apply

SQL Apply

Role-management services

services – Redo Apply – SQL Apply • Role-management services Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

Types of Services The following types of services are available with Data Guard:

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

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

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

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

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

Oracle Database 10g: Data Guard Administration

1-8

Role Transitions: Switchover and Failover

Oracle Data Guard supports two role-transition operations:

Switchover

Planned role reversal

Used for OS or hardware maintenance

Failover

Unplanned role reversal

Use in emergency

Zero or minimal data loss depending on choice of data protection mode

Role-transition operations are not automatically invoked.

mode • Role-transition operations are not automatically invoked. Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Role Transitions: Switchover and Failover

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

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

Failover: You invoke a failover operation when a catastrophic failure occurs on the primary database and there is no possibility of recovering the primary database in a timely manner. During a failover operation, the failed primary database is removed from the Data Guard environment, and a standby database assumes the primary database role. You invoke the failover operation on the standby database that you want to fail over to the primary role.

Oracle Database 10g: Data Guard Administration

1-9

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

Oracle Database 10g: Data Guard Administration

1-10

Data-Protection Modes

Maximum protection

Maximum availability

Maximum performance

• Maximum protection • Maximum availability • Maximum performance Copyright © 2005, Oracle. All rights reserved.
• Maximum protection • Maximum availability • Maximum performance Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10g: Data Guard Administration

1-11

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

Oracle Database 10g: Data Guard Administration

1-12

Benefits of Implementing Oracle Data Guard

Oracle Data Guard provides the following benefits:

Continuous service through disasters or crippling data failures

Complete data protection against corruptions and data loss

Efficient use of system resources

Elimination of idle standby systems

Flexible configuration of your system to meet business protection and recovery requirements

Centralized management

business protection an d recovery requirements • Centralized management Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

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

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

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

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

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

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

Oracle Database 10g: Data Guard Administration

1-13

Role of Data Guard in a High Availability Architecture

Computer

failures

in a High Availability Architecture Computer failures RAC Storage failure Human error Corruption Data

RAC

Storage

failure

Architecture Computer failures RAC Storage failure Human error Corruption Data failures Site failure ASM

Human

error

Computer failures RAC Storage failure Human error Corruption Data failures Site failure ASM Flashback

Corruption

failures RAC Storage failure Human error Corruption Data failures Site failure ASM Flashback technology
failures RAC Storage failure Human error Corruption Data failures Site failure ASM Flashback technology
failures RAC Storage failure Human error Corruption Data failures Site failure ASM Flashback technology
failures RAC Storage failure Human error Corruption Data failures Site failure ASM Flashback technology
failures RAC Storage failure Human error Corruption Data failures Site failure ASM Flashback technology

Data

failures

Site

failure

Human error Corruption Data failures Site failure ASM Flashback technology Oracle HARD RMAN Data Guard

ASM

Flashback

technology

Oracle HARD

RMAN

Data Guard

Site failure ASM Flashback technology Oracle HARD RMAN Data Guard Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10g: Data Guard Administration

1-14

Role of Data Guard in a High Availability Architecture

• Online schema and data reorganization Data changes • Partitioned tables and indexes • Dynamic
• Online schema and
data reorganization
Data
changes
• Partitioned tables
and indexes
• Dynamic resource
provisioning
Planned
down time
• Rolling patch updates
System
changes
• Rolling release upgrade
using Data Guard
SQL Apply
System changes • Rolling release upgrade using Data Guard SQL Apply Copyright © 2005, Oracle. All

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10g: Data Guard Administration

1-15

Oracle Data Guard and Real Application Clusters

Oracle Data Guard and Real Application Clusters are complementary and can be used together:

Real Application Clusters provides high availability.

Oracle Data Guard provides disaster protection and prevents data loss.

Oracle Data Guard provi des disaster protection and prevents data loss. Copyright © 2005, Oracle. All

Copyright © 2005, Oracle. All rights reserved.

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

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

• Increased scalability

Oracle Data Guard provides disaster protection and prevents data loss by:

• Maintaining transactionally consistent copies of the primary database

• Protecting against data corruption

• Protecting against user errors

• Not requiring expensive and complex mirroring of hardware or software

RAC is covered in greater detail in the “Using Data Guard with RAC” lesson.

Oracle Database 10g: Data Guard Administration

1-16

Maximum Availability Architecture

Oracle

Application

Server

Maximum Availability Architecture Oracle Application Server Clients Oracle Application Server WAN traffic manager
Maximum Availability Architecture Oracle Application Server Clients Oracle Application Server WAN traffic manager
Maximum Availability Architecture Oracle Application Server Clients Oracle Application Server WAN traffic manager

Clients

Availability Architecture Oracle Application Server Clients Oracle Application Server WAN traffic manager RAC
Availability Architecture Oracle Application Server Clients Oracle Application Server WAN traffic manager RAC
Availability Architecture Oracle Application Server Clients Oracle Application Server WAN traffic manager RAC
Availability Architecture Oracle Application Server Clients Oracle Application Server WAN traffic manager RAC

Oracle

Application

Server

Application Server Clients Oracle Application Server WAN traffic manager RAC production database Data Guard RAC

WAN traffic

manager

Oracle Application Server WAN traffic manager RAC production database Data Guard RAC RAC physical

RAC

production

database

Data Guard

RAC

RAC

physical

logical

standby

standby

database

database

RAC physical logical standby standby database database Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10g: Data Guard Administration

1-17

Summary

In this lesson, you should have learned how to:

Describe the basic components of Oracle Data Guard

Describe the differences between physical and logical standby databases

Determine when Oracle Data Guard is an appropriate solution in your Oracle Database configuration

Explain the use of Data Guard in high availability architectures

• Explain the use of Data Guard in high availability architectures Copyright © 2005, Oracle. All

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration

1-18

Practice 1: Overview

This practice covers the following topics:

Reviewing the factors that affect planned and unplanned down time

Reviewing the differences between physical and logical standby databases

Reviewing the components of Oracle Data Guard

standby databases • Reviewing the components of Oracle Data Guard Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration

1-19

Understanding the Oracle Data Guard Architecture Copyright © 2005, Oracle. All rights reserved.

Understanding the Oracle Data Guard Architecture

Understanding the Oracle Data Guard Architecture Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Objectives

After completing this lesson, you should be able to do the following:

Describe the Data Guard architecture

Explain the operational requirements of Data Guard

Describe how Data Guard processes, transports, and applies redo logs

Describe standby database modes

transports, and applies redo logs • Describe standby database modes Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10 g : Data Guard Administration

2-2

Data Guard Operational Requirements:

Hardware and Operating System

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

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

The operating system for the primary and standby databases must be the same, but the operating system releases can be different.

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

the OS allows you to mount more than one database with the same name. Copyright ©

Copyright © 2005, Oracle. All rights reserved.

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

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

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

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

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

Oracle Database 10 g : Data Guard Administration

2-3

Data Guard Operational Requirements:

Oracle Database Software

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

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

Each database must have its own control file.

Primary database must operate in ARCHIVELOG mode.

Enable FORCE LOGGING on the primary database before taking data file backups for standby creation.

If any databases use ASM and/or OMF, all should use the same combination.

any databases use ASM and/or OMF, all should use the same combination. Copyright © 2005, Oracle.

Copyright © 2005, Oracle. All rights reserved.

Oracle Database Software Requirements

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

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

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

• The primary database and each standby database must have their own control files.

• The primary database must be configured in ARCHIVELOG mode.

Oracle Database 10 g : Data Guard Administration

2-4

Oracle Database Software Requirements (continued)

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

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

Oracle Database 10 g : Data Guard Administration

2-5

Oracle Data Guard: Architecture

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

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10 g : Data Guard Administration

2-6

Primary Database Flow

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

Copyright © 2005, Oracle. All rights reserved.

Primary Database Flow On the primary database, Data Guard log transport services use the following processes:

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

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

Fetch archive log (FAL) (physical standby databases only): FAL provides a client/server mechanism for resolving gaps detected in the range of archived redo logs that are generated at the primary database and received at the standby database. This process is started only when needed and shuts down as soon as it is finished. It is very likely you will not see this process running. Note: You can configure a primary database to ship redo information by using LGWR or ARCn, but not both.

Oracle Database 10 g : Data Guard Administration

2-7

Standby Database Flow

Primary database transactions (MRP only) LGWR RFS Online Standby redo redo logs logs FAL ARC0
Primary
database
transactions
(MRP only)
LGWR
RFS
Online
Standby
redo
redo logs
logs
FAL
ARC0
ARC0
Archived redo
logs
Oracle net

MRP or

LSP

FAL ARC0 ARC0 Archived redo logs Oracle net MRP or LSP Standby database Backup Reports Archived

Standby

database

Archived redo logs Oracle net MRP or LSP Standby database Backup Reports Archived redo logs Copyright
Archived redo logs Oracle net MRP or LSP Standby database Backup Reports Archived redo logs Copyright

Backup

Reports

Archived redo

logs

Oracle net MRP or LSP Standby database Backup Reports Archived redo logs Copyright © 2005, Oracle.

Copyright © 2005, Oracle. All rights reserved.

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

Remote file server (RFS) process: RFS receives redo information from the primary database. RFS can write the redo into standby redo logs or directly to archived redo logs. Note: Standby redo logs are optional. The use of standby redo logs is discussed in more detail later in the lesson.

Archiver (ARCn) process: The ARCn process archives the standby redo logs.

Managed recovery process (MRP): For physical standby databases only, MRP applies archived redo log information to the physical standby database. If you start the managed recovery with the SQL statement ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; this foreground session performs the recovery. If you use the optional clause DISCONNECT [FROM SESSION], the MRP background process starts. If you use Data Guard broker to manage your standby databases, the broker always starts the MRP background process for a physical standby database.

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

Oracle Database 10 g : Data Guard Administration

2-8

Standby Redo Logs

 

Standby

Archived

Redo from

redo logs

redo logs

primary database

primary database
Redo from redo logs redo logs primary database ARC0 RFS MRP/LSP Standby database Copyright © 2005,
ARC0
ARC0
from redo logs redo logs primary database ARC0 RFS MRP/LSP Standby database Copyright © 2005, Oracle.
from redo logs redo logs primary database ARC0 RFS MRP/LSP Standby database Copyright © 2005, Oracle.
RFS MRP/LSP
RFS
MRP/LSP
Standby database
Standby database

Copyright © 2005, Oracle. All rights reserved.

Standby Redo Logs

A standby redo log is used only when the database is in the standby role to store redo data

received from the primary database. Standby redo logs form a separate pool of log file groups.

Configuring standby redo log files is highly recommended on all standby databases in a Data Guard configuration, including the primary database to aid in role reversal.

A standby redo log is required to implement:

• The maximum protection and maximum availability levels of data protection

• Real-time apply

• Cascaded redo log destinations

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

Oracle Database 10 g : Data Guard Administration

2-9

Data Guard Redo Apply: Architecture

Production

database

Physical standby database

Architecture Production database Physical standby database Redo Redo transport apply Backup Redo stream

Redo

Redo

transport

apply

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

Backup

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

Redo

stream

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

Primary

database

Physical standby database

apply Backup Redo stream Primary database Physical standby database Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Data Guard Redo Apply: Architecture

The Data Guard physical standby Redo Apply architecture consists of:

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

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

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

Oracle Database 10 g : Data Guard Administration

2-10

Data Guard Redo Apply: Architecture (continued)

• The standby database, which is updated by redo that is automatically shipped from the primary database. The redo can be shipped because it is generated or archived on the primary database.

- Redo is applied to each standby database by using standard Oracle recovery techniques.

- During planned down time, you can perform a switchover to a standby database.

- When a failure occurs, you may fail over to one of the standby databases.

- The physical standby database can also be used to back up the primary database.

Oracle Database 10 g : Data Guard Administration

2-11

Data Guard SQL Apply: Architecture

Production

database

Logical standby database

Architecture Production database Logical standby database SQL Redo transport Apply Transform redo information into
Architecture Production database Logical standby database SQL Redo transport Apply Transform redo information into
Architecture Production database Logical standby database SQL Redo transport Apply Transform redo information into
Architecture Production database Logical standby database SQL Redo transport Apply Transform redo information into
Architecture Production database Logical standby database SQL Redo transport Apply Transform redo information into

SQL

Production database Logical standby database SQL Redo transport Apply Transform redo information into SQL

Redo transport

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

Transform redo information into SQL

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

Reports

Primary

database

Logical standby database

information into SQL Reports Primary database Logical standby database Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10 g : Data Guard Administration

2-12

SQL Apply Process: Architecture

LCR LCR :
LCR
LCR
:

Shared

pool

R e a d e r Preparer Redo Builder

Reader

R e a d e r Preparer Redo

Preparer

R e a d e r Preparer Redo
R e a d e r Preparer Redo
R e a d e r Preparer Redo
R e a d e r Preparer Redo

Redo

Builder

Shared pool R e a d e r Preparer Redo Builder records Log Mining Redo data

records

Log Mining

a d e r Preparer Redo Builder records Log Mining Redo data from primary database Logical
a d e r Preparer Redo Builder records Log Mining Redo data from primary database Logical

Redo data from primary database

Logical change records not grouped into transactions

Transaction

groups

Apply processing

Applier

Coordinator

Transaction groups Apply processing Applier Coordinator Analyzer Data files Transactions sorted in dependency order

Analyzer

groups Apply processing Applier Coordinator Analyzer Data files Transactions sorted in dependency order
groups Apply processing Applier Coordinator Analyzer Data files Transactions sorted in dependency order

Data files

Apply processing Applier Coordinator Analyzer Data files Transactions sorted in dependency order Transactions to be
Apply processing Applier Coordinator Analyzer Data files Transactions sorted in dependency order Transactions to be

Transactions

sorted in

dependency

order

Transactions to be applied

files Transactions sorted in dependency order Transactions to be applied Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

SQL Apply Process: Architecture

SQL Apply uses a collection of parallel execution servers and background processes that apply changes from the primary database to the logical standby database as follows:

• The reader process reads redo records from the archived redo log files.

• The preparer processes convert the block changes into table changes or logical change records (LCRs). At this point, the LCRs do not represent any specific transactions.

• The builder process assembles completed transactions from the individual LCRs.

• The analyzer process examines the records, possibly eliminating transactions and identifying dependencies between the different transactions.

• The coordinator process (LSP):

- Assigns transactions

- Monitors dependencies between transactions and coordinates scheduling

- Authorizes the commitment of changes to the logical standby database

• The applier process:

- Applies the LCRs to the database

- Asks the coordinator process to approve transactions with unresolved dependencies

- Commits the transactions

Oracle Database 10 g : Data Guard Administration

2-13

Real-Time Apply

RFS

Real-Time Apply RFS Standby redo log files ARC0 Primary database MRP or LSP Standby database Archived

Standby

redo log

files

ARC0

Real-Time Apply RFS Standby redo log files ARC0 Primary database MRP or LSP Standby database Archived

Primary

database

MRP or LSP

RFS Standby redo log files ARC0 Primary database MRP or LSP Standby database Archived redo log
RFS Standby redo log files ARC0 Primary database MRP or LSP Standby database Archived redo log

Standby

database

Archived

redo log

files

ARC0 Primary database MRP or LSP Standby database Archived redo log files Copyright © 2005, Oracle.

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10 g : Data Guard Administration

2-14

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

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

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

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

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

Oracle Database 10 g : Data Guard Administration

2-15

Setting the DB_UNIQUE_NAME Parameter

San Francisco

San Francisco SF1_DB

SF1_DB

DB_UNIQUE_NAME = SF1_DB

DB_UNIQUE_NAME Parameter San Francisco SF1_DB DB_UNIQUE_NAME = SF1_DB Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10 g : Data Guard Administration

2-16

Specifying Role-Based Destinations

Primary

Standby

database

database

Not used
Not used

LOG_ARCHIVE_DEST_2= location=

"/u01/app/oracle/oradata/orcldg2/arc",

valid_for=(STANDBY_LOGFILE,STANDBY_ROLE) DB_UNIQUE_NAME = HRDB2

valid_for=(STANDBY_LOGFILE,STANDBY_ROLE) DB_UNIQUE_NAME = HRDB2 Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Specifying Role-Based Destinations The VALID_FOR attribute of the LOG_ARCHIVE_DEST_ n initialization parameter allows you to identify exactly when the archive destination is to be used, as well as for which type of log file it is used. The attribute uses a keyword pair to identify the source of the archival as well as the database role. In the example in the slide, there is a destination on the standby database and the primary database defined with the VALID_FOR setting shown. This destination is only to be used on the standby database after a switchover, when the standby becomes a primary. The destination on the old primary is ignored when it becomes a standby. You supply two values for the VALID_FOR attribute: archival_source and database_role. The archival_source keywords are the following:

ONLINE_LOGFILE: This destination is used only when archiving online redo log files.

STANDBY_LOGFILE: This destination is used only when archiving standby redo log files or receiving archive logs from another database.

ALL_LOGFILES: This destination is used when archiving either online or standby redo log files.

Oracle Database 10 g : Data Guard Administration

2-17

Specifying Role-Based Destinations (continued) The database_role keywords are the following:

PRIMARY_ROLE: This destination is used only when the database is in the primary database role.

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

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

Oracle Database 10 g : Data Guard Administration

2-18

Combinations for VALID_FOR

Combination

Primary

Physical

Logical

ONLINE_LOGFILE, PRIMARY_ROLE

Valid

Ignored

Ignored

ONLINE_LOGFILE, STANDBY_ROLE

Ignored

Ignored

Valid

ONLINE_LOGFILE, ALL_ROLES

Valid

Ignored

Valid

STANDBY_LOGFILE,STANDBY_ROLE

Ignored

Valid

Valid

STANDBY_LOGFILE, ALL_ROLES

Ignored

Valid

Valid

ALL_LOGFILES, PRIMARY_ROLE

Valid

Ignored

Ignored

ALL_LOGFILES, STANDBY_ROLE

Ignored

Valid

Valid

ALL_LOGFILES, ALL_ROLES

Valid

Valid

Valid

Valid Valid ALL_LOGFILES , ALL_ROLES Valid Valid Valid Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

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

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

Oracle Database 10 g : Data Guard Administration

2-19

Identifying Destination Settings

SQL> SELECT DEST_ID,VALID_TYPE,VALID_ROLE,VALID_NOW

2 FROM V$ARCHIVE_DEST;

DEST_ID VALID_TYPE

VALID_ROLE

VALID_NOW

------- --------------- ------------ --------------

1

ONLINE_LOGFILE ALL_ROLES YES

2

STANDBY_LOGFILE STANDBY_ROLE YES

3

ALL_LOGFILES ALL_ROLES UNKNOWN

4

ALL_LOGFILES ALL_ROLES UNKNOWN

5

ALL_LOGFILES ALL_ROLES UNKNOWN

6

ALL_LOGFILES ALL_ROLES UNKNOWN

7

ALL_LOGFILES ALL_ROLES UNKNOWN

8

ALL_LOGFILES ALL_ROLES UNKNOWN

9

ALL_LOGFILES ALL_ROLES UNKNOWN

10

ALL_LOGFILES ALL_ROLES UNKNOWN

11

ALL_LOGFILES ALL_ROLES YES

11 rows selected.

UNKNOWN 11 ALL_LOGFILES ALL_ROLES YES 11 rows selected. Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

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

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

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

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

Oracle Database 10 g : Data Guard Administration

2-20

Standby Redo Log Configuration

Online Standby redo redo Redo logs logs shipment RFS Primary Standby database database
Online
Standby
redo
redo
Redo
logs
logs
shipment
RFS
Primary
Standby
database
database
Redo logs logs shipment RFS Primary Standby database database Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

• There are no standby redo logs.

• It cannot find the same size standby redo log as the incoming online redo log file.

• All of the standby redo logs of the correct size have not yet been archived.

Oracle Database 10 g : Data Guard Administration

2-21

Number of Standby Redo Logs

The following clauses of the CREATE DATABASE statement affect the number of redo logs that you can create:

MAXLOGFILES: Maximum number of groups of standby redo logs and online redo logs per database

MAXLOGMEMBERS: Maximum number of members per group

per database • MAXLOGMEMBERS : Maximum number of members per group Copyright © 2005, Oracle. All

Copyright © 2005, Oracle. All rights reserved.

Number of Standby Redo Logs The following clauses limit the number of standby redo log groups that you can add to a database:

• The MAXLOGFILES clause of the CREATE DATABASE statement for the primary database determines the maximum number of groups of standby redo logs and online redo log groups per database. The sum of online log groups and standby redo log groups must be equal to or less than MAXLOGFILES.

• The MAXLOGMEMBERS clause of the CREATE DATABASE statement that is used for the primary database determines the maximum number of members per group. The only way to override the limits that are specified by the MAXLOGFILES and MAXLOGMEMBERS clauses is to re-create the primary database or the control file.

See Oracle Database SQL Reference and your operating system–specific Oracle documentation for the default and allowed values of the MAXLOGFILES and MAXLOGMEMBERS clauses.

Oracle Database 10 g : Data Guard Administration

2-22

Using SQL to Add Standby Redo Logs

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

SQL> ALTER DATABASE ADD STANDBY LOGFILE

2 ('/oracle/dbs/log1c.rdo',

3 '/oracle/dbs/log2c.rdo') SIZE 500K;

Add members to a group with the following statement:

SQL> ALTER DATABASE ADD STANDBY LOGFILE MEMBER

2 '/oracle/dbs/log2b.rdo' TO GROUP 2;

View information about the groups as follows:

SQL> SELECT * FROM V$LOGFILE

2 WHERE TYPE = 'STANDBY';

SQL> SELECT * FRO M V$LOGFILE 2 WHERE TYPE = 'STANDBY'; Copyright © 2005, Oracle. All

Copyright © 2005, Oracle. All rights reserved.

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

SQL> SELECT GROUP#,STATUS,FIRST_CHANGE# 2 FROM V$STANDBY_LOG; GROUP# STATUS FIRST_CHANGE# ---------- ---------- -------------

3 ACTIVE

144545

4 UNASSIGNED

0

5 UNASSIGNED

0

Oracle Database 10 g : Data Guard Administration

2-23

Using Enterprise Manager to Add Standby Redo Logs

Using Enterprise Manager to Add Standby Redo Logs Copyright © 2005, Oracle. All rights reserved.
Using Enterprise Manager to Add Standby Redo Logs Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

Oracle Database 10 g : Data Guard Administration

2-24

Standby Database Modes

You can maintain the standby data in one of the following modes:

For physical standby databases

Redo Apply

Open read-only mode

For logical standby databases

Open read/write mode

mode • For logical standby databases – Open read/write mode Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

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

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

Open read-only mode: If you want to use the standby database for reporting purposes, then open it in read-only mode in a Data Guard environment. Log apply services cannot apply archived redo logs to the standby database when it is in this mode, but the primary database continues to ship redo to the standby database. You can easily change between managed recovery mode and read-only mode. In most

implementations of a Data Guard environment, you may want to make this transition at various times so that you can do one of the following:

• Update a physical standby database that is used primarily for reporting

• Ensure that data is correctly applied to a physical standby database that is used primarily for disaster protection

Oracle Database 10 g : Data Guard Administration

2-25

Standby Database Modes (continued)

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

Oracle Database 10 g : Data Guard Administration

2-26

Summary

In this lesson, you should have learned how to describe the following:

Data Guard architecture processes

Operational requirements of a Data Guard environment

How Data Guard processes, transports, and applies redo logs

Modes of standby databases and when to use each mode

redo logs • Modes of standby databases and when to use each mode Copyright © 2005,

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10 g : Data Guard Administration

2-27

Practice 2-1: Overview (Architecture)

This practice covers the following topics:

Reviewing the Oracle Data Guard architecture

Reviewing the processes that Data Guard uses to transport and apply redo logs

Reviewing the modes that are used to recover a primary database

logs • Reviewing the modes that are used to recover a primary database Copyright © 2005,

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10 g : Data Guard Administration

2-28

Practice 2-2: Overview (Installing the Oracle Management Agent)

This practice covers the following topics:

Installing the Oracle Management Agent

Configuring monitoring credentials for your database

Management Agent • Configuring monitoring credentials for your database Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10 g : Data Guard Administration

2-29

Practice 2-3: Overview (Configuring Your Primary Database)

This practice covers the following topics:

Reviewing your primary database configuration

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

primary database in preparation for creating a Data Guard configuration Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10 g : Data Guard Administration

2-30

Data Guard Broker and Enterprise Manager Copyright © 2005, Oracle. All rights reserved.

Data Guard Broker and Enterprise Manager

Data Guard Broker and Enterprise Manager Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Objectives

After completing this lesson, you should be able to do the following:

Describe the Data Guard broker architecture

Describe the Data Guard broker components

Explain the benefits of the Data Guard broker

Explain Data Guard broker configurations

Use Enterprise Manager to manage your Data Guard configuration

Invoke DGMGRL to manage your Data Guard configuration

configuration • Invoke DGMGRL to manage your Data Guard configuration Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Data Guard Administration

3-2

Features of Data Guard Broker

The Data Guard broker is a distributed management framework.

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

With the broker, you can perform all management operations locally or remotely through easy-to-use interfaces:

Oracle Enterprise Manager 10g Grid Control

A command-line interface: DGMGRL

Manager 10 g Grid Control – A command-line interface: DGMGRL Copyright © 2005, Oracle. All rights

Copyright © 2005, Oracle. All rights reserved.

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

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

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

• Managing an entire Data Guard configuration (including all databases, log transport services, and log apply services) through a client connection to any database in the configuration

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

• Monitoring the status of the entire configuration, capturing diagnostic information, reporting statistics such as the log apply rate and the redo generation rate, and detecting problems quickly with centralized monitoring, testing, and performance tools

Oracle Database 10g: Data Guard Administration

3-3

Data Guard Broker: Components

Client-side:

Oracle Enterprise Manager 10g Grid Control

DGMGRL (command-line interface)

Server-side: Data Guard monitor

DMON process

Configuration files

Data Guard monitor – DMON process – Configuration files Copyright © 2005, Oracle. All rights reserved.
Data Guard monitor – DMON process – Configuration files Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

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

• Oracle Enterprise Manager

DGMGRL, which is the Data Guard command-line interface (CLI)

On the server, Data Guard monitor is a broker component that is integrated with the Oracle database. Data Guard monitor comprises the Data Guard monitor process ( DMON) and broker configuration files, with which you can control the databases of that configuration, modify their behavior at run time, monitor the overall health of the configuration, and provide notification of other operational characteristics. The configuration file contains profiles that describe the states and properties of the databases in the configuration. Associated with each database are various properties that the DMON process uses to control the database’s behavior. The properties are recorded in the configuration file as a part of the database’s object profile that is stored there. Many database properties are used to control database initialization parameters related to the Data Guard environment.

Oracle Database 10g: Data Guard Administration

3-4

Data Guard Broker: Configurations

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

Chicago

Chicago Primary site

Primary

site

Oracle Net

at another location. Chicago Primary site Oracle Net Boston Standby site Copyright © 2005, Oracle. All

Boston

Boston Standby site

Standby

site

location. Chicago Primary site Oracle Net Boston Standby site Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Data Guard Broker: Configurations A Data Guard configuration consists of one primary database and up to nine standby databases. The databases in a Data Guard configuration are typically dispersed geographically and are connected by Oracle Net.

A Data Guard broker configuration is a logical grouping of the primary and standby databases in a Data Guard configuration. The broker’s DMON process configures and maintains the broker configuration components as a unified group of resource objects that you can manage and monitor as a single unit. When you enter a command through Enterprise Manager or the CLI, the appropriate DMON process does the following:

Carries out your request on its local database resource object and site object

Updates the broker configuration file

Communicates with the DMON process on the other site

Oracle Database 10g: Data Guard Administration

3-5

Data Guard Broker: Management Model

Data Guard Broker Configuration

Broker-controlled databases Primary database Standby database Standby database Standby database Standby database
Broker-controlled
databases
Primary database
Standby database
Standby database
Standby database
Standby database
Standby database
Standby database
Standby database
Standby database
Standby database
Instances
Instances
Standby database Standby database Standby database Instances Instances Copyright © 2005, Oracle. All rights reserved.

Copyright © 2005, Oracle. All rights reserved.

Data Guard Broker: Management Model

The Data Guard broker performs operations on logical objects:

• Configuration of databases

• A single database

A broker configuration consists of:

• A configuration object: A named collection of database profiles. A database profile is a description of a database object, including its current state, current status, and properties.

Database objects: Objects corresponding to primary or standby databases

Instance objects: A database object may be comprised of one or more instance objects if it is a RAC database. The broker supports one or more Data Guard configurations, each of which includes a profile for one primary database as well as profiles for up to nine physical, logical, RAC or non-RAC standby databases.

Oracle Database 10g: Data Guard Administration

3-6

Data Guard Broker: Architecture

Graphical user interface or command-line interface

Graphical user interface or command-line interface Data Guard Configuration Standby site 9 Standby site 2
Data Guard Configuration Standby site 9 Standby site 2 Primary site Standby site 1 Configuration
Data Guard Configuration