Oracle Data Guard Broker

and

Managing Client Connectivity

By Mr. AKAL SINGH (OCM)

Oracle Data Guard Broker: Features

• Automated creation of Data Guard configurations

incorporating a primary database, a new or existing standby

database, redo transport services, and log apply services.

• Adding new or existing standby databases to Data Guard

configuration.

• Managing an entire Data Guard configuration (including all

databases, redo transport services, and log apply services)

• Monitoring the status of the entire configuration, capturing

diagnostic information, reporting statistics, and detecting

problems

• With the broker, you can perform all management operations

locally or remotely with easy-to-use interfaces:

– Oracle Enterprise Manager Grid Control

– DGMGRL (a command-line interface)

Data Guard Broker: Components

• Client-side:

– Oracle Enterprise Manager Grid Control

– DGMGRL (command-line interface)

• Server-side: Data Guard monitor

– DMON process

– Configuration files

Data Guard Broker: Configurations

The most common configuration is a primary database at one

location and a standby database at another location.

nodePrmy

Primary

site

nodeStdby1

Standby

site

Oracle Net

Data Guard Broker: Management Model

Data Guard Broker Configuration

Primary database

Broker-controlled

databases

Standby database Standby database

Standby database Standby database

Standby database Standby database

Standby database Standby database

Standby database

Instances Instances

Primary site

Standby site 30

Standby site ..

Data Guard Broker: Architecture

Graphical user interface or

command-line interface

DMON

Archived redo logs

Online redo logs

Standby site 1

Oracle Net

Standby redo logs

Archived redo logs

Log apply

services

Data Guard Configuration

Log transport services

Primary database

DMON

Configuration files

Configuration files

Standby database

Standby redo logs

Online redo logs

Data Guard Monitor: DMON Process

• Server-side background process

• Part of each database instance in the configuration

• Created when you start the broker

• Performs requested functions and monitors the resource

• Communicates with other DMON processes in the

configuration

• Updates the configuration file

• Creates the drc<SID> trace file in the location set by the

DIAGNOSTIC_DEST initialization parameter

• Modifies initialization parameters during role transitions as

necessary

Benefits of Using the Data Guard Broker

• Enhances the high-availability, data protection, and

disaster protection capabilities inherent in Oracle Data

Guard by automating both configuration and monitoring

tasks

• Streamlines the process for any one of the standby

databases to replace the primary database and take over

production processing

• Enables easy configuration of additional standby databases

• Provides simplified, centralized, and extended management

• Automatically communicates between the databases in a

Data Guard configuration by using Oracle Net Services

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

databases in the configuration

Comparing Configuration Management

With and Without the Data Guard Broker

With the Broker Without the Broker

General Manage databases as one Manage databases separately

Creation of the

standby database

Use Grid Control wizards Manually create files

Configuration and

management

Configure and manage from

single interface

Set up services manually for

each database

Monitoring • Monitor continuously

• Unified status and reports

• Integrate with EM events

Monitor each database

individually through views

Control Invoke role transitions with

a single command

Coordinate sequences of

multiple commands across

database sites for role

transitions

Using the Command-Line Interface

of the Data Guard Broker

DGMGRL> connect sys/oracle_4U

Connected.

DGMGRL> show configuration verbose

Configuration - DGConfig1

Protection Mode: MaxPerformance

Databases:

Prmy - Primary database

Stdby1 - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

Creating a Data Guard Broker Configuration

Data Guard Broker: Requirements

• Oracle Database Enterprise Edition

• Single-instance or multi-instance environment

• COMPATIBLE parameter: Set to 10.2.0.1.0 or later for

primary and standby databases

• Oracle Net Services network files: Must be configured for

the primary database and any existing standby databases.

Enterprise Manager Grid Control configures files for new

standby databases.

• GLOBAL_DBNAME attribute: Set to a concatenation of

db_unique_name_DGMGRL.db_domain

Data Guard Broker: Requirements

• DG_BROKER_START initialization parameter: Set to TRUE

• Primary database: ARCHIVELOG mode

• All databases: MOUNT or OPEN mode

• DG_BROKER_CONFIG_FILEn: Configured for any RAC

databases

Additionally :

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

initialization parameters.

Data Guard Monitor: Configuration File

• The broker configuration file is:

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

– Managed automatically by the DMON process

• The configuration file and a copy are created at each managed site with default names:

– dr1<db_unique_name>.dat

– dr2<db_unique_name>.dat

• Configuration file default locations are operating system specific:

– Default location for UNIX and Linux: ORACLE_HOME/dbs

– Default location for Windows: ORACLE_HOME\database

• Use DG_BROKER_CONFIG_FILEn to override the default

path name and file name.

Creating a Broker Configuration

1. Invoke DGMGRL and connect to the primary database.

2. Define the configuration, including a profile for the primary

database.

3. Add standby databases to the configuration.

4. Enable the configuration, including the databases.

Defining the Broker Configuration and

the Primary Database Profile

DGMGRL> CREATE CONFIGURATION 'DGConfig1' AS

> PRIMARY DATABASE IS prmy

> CONNECT IDENTIFIER IS prmy;

Configuration "DGConfig1" created with

primary

database "prmy“

DGMGRL>

Adding a Standby Database to the Configuration

DGMGRL> ADD DATABASE stdby AS

> CONNECT IDENTIFIER IS stdby;

Database “stdby" added

DGMGRL>

Enabling the Configuration

DGMGRL> ENABLE CONFIGURATION;

Enabled.

DGMGRL> SHOW CONFIGURATION

Configuration - DGConfig1

Protection Mode: MaxPerformance

Databases:

prmy - Primary database

stdby - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

• To alter a database property:

• To alter the state of the standby database:

• To alter the state of the primary database:

Changing Database Properties and States

DGMGRL> EDIT DATABASE stdby

> SET PROPERTY LogXptMode='SYNC';

DGMGRL> EDIT DATABASE stdby SET STATE='APPLY-OFF';

DGMGRL> EDIT DATABASE prmy

> SET STATE='TRANSPORT-OFF';

When the broker configuration is enabled, the databases are in one of four states:

TRANSPORT-ON (applicable only to the primary database)

TRANSPORT-OFF (applicable only to the primary database)

APPLY-ON (applicable only to a physical or logical standby database)

APPLY-OFF (applicable only to a physical or logical standby database)

Managing Redo Transport Services

by Using DGMGRL

Specify database properties to manage redo transport services:

• DGConnectIdentifier

• LogXptMode

• LogShipping

Specifying the Connection Identifier by Using the DGConnectIdentifier Property

• DGConnectIdentifier:

– Specifies the connection identifier that is used by the broker

to connect to a database and redo transport services

– Is set when a database is either added to the Data Guard

broker configuration to the value specified in the optional CONNECT IDENTIFIER CLAUSE, or is extracted from the

SERVICE attribute of the LOG_ARCHIVE_DEST_n

initialization parameter

• The DGConnectIdentifier value is used to set the

FAL_SERVER and FAL_CLIENT initialization parameters.

Managing the Redo Transport Service by Using the LogXptMode Property

Definitions of LOG_ARCHIVE_DEST_n Attributes

• ASYNC: Redo data that is generated by a transaction need not

have been received at a destination that has this attribute before

the transaction can commit.

• SYNC: Redo data that is generated by a transaction must have

been received by every enabled destination that has this attribute

before the transaction can commit.

• AFFIRM and NOAFFIRM: Control whether redo transport services

use synchronous or asynchronous disk I/O to write redo data to

the archived redo log files

– AFFIRM: Specifies that a redo transport destination acknowledges

received redo data after writing it to the standby redo log

– NOAFFIRM: Specifies that a redo transport destination

acknowledges received redo data before writing it to the standby

redo log

Managing the Redo Transport Service by Using the LogXptMode Property

• The redo transport service must be set up for the chosen

data protection mode.

• Use the LogXptMode property to set the redo transport

services:

– ASYNC

— Sets the ASYNC and NOAFFIRM attributes of

LOG_ARCHIVE_DEST_n

— Required for maximum performance mode

– SYNC

— Sets the SYNC and AFFIRM attributes of

LOG_ARCHIVE_DEST_n

— Required for maximum protection and maximum availability

modes

Setting LogXptMode to ASYNC

Primary database

transactions

RFS

MRP or LSP

Archived redo

logs

ARC0

Standby

database

Standby

redo logs O

rac

le N

et

(Real-time

apply)

Sets the ASYNC and NOAFFIRM

attributes of LOG_ARCHIVE_DEST_n

Standby ack

LGWR

Online

redo

logs

Redo buffer

LNSn

Setting LogXptMode to SYNC

LGWR

Primary database

transactions

Online

redo

logs

RFS

MRP or LSP

Archived redo

logs

ARC0

Standby

database

Standby

redo logs O

rac

le N

et

(Real-time

apply)

Sets the SYNC and AFFIRM

attributes of LOG_ARCHIVE_DEST_n

Standby ack

LNSn

Redo buffer

Controlling the Shipping of Redo Data by Using the LogShipping Property

• LogShipping controls whether redo transport services

can send redo data to a specified standby database.

• LogShipping is applicable only when the primary

database state is set to TRANSPORT-ON.

Managing Client Connectivity

Understanding Client Connectivity

in a Data Guard Configuration

Be aware of the following issues when you manage client

connectivity in a Data Guard configuration:

• Databases reside on different hosts in a Data Guard

configuration.

• Clients must connect to the correct database:

– Primary

– Logical standby

– Snapshot standby

– Physical standby with real-time query

• If clients send connection requests to the wrong host, they

may be connected to the wrong database or receive an

error.

• Clients must automatically reconnect to the correct

database in the event of a failover.

Understanding Client Connectivity:

Using Local Naming

Primary database

Standby database

Ora

cle

Ne

t

DG_PROD

Listener

The tnsnames.ora file would look similar to the following:

PROD = (DESCRIPTION =

(ADDRESS=(PROTOCOL = TCP)(HOST = EDBVR6P1)(PORT = 1521))

(ADDRESS=(PROTOCOL = TCP)(HOST = EDBVR6P2)(PORT = 1521))

(CONNECT_DATA = (SERVICE_NAME = DG_PROD)))

Preventing Clients from Connecting

to the Wrong Database

• Use database services to prevent clients from connecting

to the wrong database in the Data Guard configuration.

• Database services act as an abstraction layer between the

client and database instances.

• Database services register with listeners.

• Clients connect to database services instead of database

instances.

• Listeners use registration details to determine which

instances support a particular service at a particular

moment in time.

• Listeners then direct connection requests to the correct

instances; otherwise, the appropriate error is returned.

Oracle Services

• To manage workloads or a group of applications, you can

define services for a particular application or a subset of an

application’s operations.

• You can also group work by type under services.

• For example OLTP users can use one service while batch

processing can use another to connect to the database.

• Users who share a service should have the same service-

level requirements.

• Use srvctl or Enterprise Manager to manage services,

not DBMS_SERVICE.

Default Service Connections

• Application services:

– Limit of 115 services per database

• Internal services:

– SYS$BACKGROUND

– SYS$USERS

– Cannot be deleted or changed

• A special Oracle database service is created by default for

the Oracle RAC database.

• This default service is always available on all instances in

an Oracle RAC environment.

Managing Services

• Database services can be managed by using the DBMS_SERVICE package when Oracle Restart is not used.

• Database services attributes:

– Service Name: For administration of the service

– Network Name: For services that are implemented for

external client connections

– Transparent Application Failover (TAF) attributes: For TAF-

enabled client connections

Creating Services for the Data Guard

Configuration Databases

DBMS_SERVICE.CREATE_SERVICE( -

SERVICE_NAME => 'DG_PROD', -

NETWORK_NAME => 'DG_PROD', -

FAILOVER_METHOD => 'BASIC', -

FAILOVER_TYPE => 'SELECT', -

FAILOVER_RETRIES => 180, -

FAILOVER_DELAY => 1);

Understanding Client Connectivity:

Using a Database Service

Primary database

Standby database

Ora

cle

Net

DG_PROD service

Using DG_PROD

Listener Listener

Connecting Clients to the Correct Database

• Use a database event trigger to ensure that clients connect

to a database in the Data Guard configuration that is in the

correct state and role.

• If no database is in the correct state and role, the trigger

ensures that clients do not connect to a database.

• Use the trigger to start database services.

– DG_PROD: Primary database

– DG_RTQ: Physical standby database opened in READ ONLY

mode (Real-time Query)

Creating the AFTER STARTUP Trigger

CREATE TRIGGER MANAGE_SERVICES AFTER STARTUP ON DATABASE

DECLARE

ROLE VARCHAR(30);

OMODE VARCHAR(30);

BEGIN

SELECT DATABASE_ROLE INTO ROLE FROM V$DATABASE;

SELECT OPEN_MODE INTO OMODE FROM V$DATABASE;

IF ROLE = 'PRIMARY' THEN

DBMS_SERVICE.START_SERVICE ('DG_PROD');

ELSIF ROLE = 'PHYSICAL STANDBY' THEN

IF OMODE LIKE 'READ ONLY%' THEN

DBMS_SERVICE.START_SERVICE ('DG_RTQ');

END IF;

END IF;

END;

/

Configuring Role-Based Services

• Use SRVCTL to configure Oracle Clusterware–managed

services on each database in the Data Guard

configuration.

• Role changes managed by the Data Guard broker

automatically start services appropriate to the database

role.

• The service is started when ROLE matches the current role

of the database and MANAGEMENT POLICY is set to

AUTOMATIC.

• Services can be started manually.

srvctl add service -d <db_unique_name> -s <service_name>

[-l [PRIMARY][,PHYSICAL_STANDBY][,LOGICAL_STANDBY]

[,SNAPSHOT_STANDBY]]

[-y {AUTOMATIC | MANUAL}]

Example: Configuring Role-Based Services

• PAYROLL: Read-write service that always runs on the

database with the primary role

• ORDERSTATUS: Read-only service that always runs on an

Active Data Guard standby database

srvctl add service -d prmy -s DG_PROD -l PRIMARY

–m BASIC –e SELECT –w 1 –z 180

srvctl add service –d prmy –s DG_RTQ

–l PHYSICAL_STADBY

Configuring Service Names in the tnsnames.ora File

PROD = (DESCRIPTION =

(ADDRESS=(PROTOCOL = TCP)(HOST = EDBVR6P1)(PORT = 1521))

(ADDRESS=(PROTOCOL = TCP)(HOST = EDBVR6P2)(PORT = 1521))

(CONNECT_DATA = (SERVICE_NAME = DG_PROD)))

RTQ = (DESCRIPTION =

(ADDRESS=(PROTOCOL = TCP)(HOST = EDBVR6P1)(PORT = 1521))

(ADDRESS=(PROTOCOL = TCP)(HOST = EDBVR6P2)(PORT = 1521))

(CONNECT_DATA = (SERVICE_NAME = DG_RTQ)))

Automatic Failover of Applications to a New

Primary Database

In previous Oracle Database releases, user-written database

triggers were required to implement automatic failover as

follows:

• A startup trigger was used to start database services on

the new primary database.

• A role-change trigger was used to publish a FAN ONS

event to break JDBC clients still connected to the original

primary database out of a TCP timeout.

In Oracle Database 11g Release 2 (11.2), you can automate

fast failover of applications to a new primary database without

the need for user-written triggers. You must use the Data

Guard broker to use this feature.

Automatic Failover of Applications to a New

Primary Database

Primary database

Database services

Primary site Standby site

Application Tier Oracle Application

Server Clusters

Database Tier Oracle Real Application

Clusters

Manual or automatic failover

1

2

3

Data Guard Broker and Fast Application

Notification (FAN)

• The Data Guard broker publishes FAN events at failover

time.

• Applications respond to FAN events without programmatic

changes if using Oracle-integrated database clients:

– Oracle Database JDBC

– Oracle Database Oracle Call Interface (OCI)

– Oracle Database ODP.NET

• Clients that receive FAN events can be configured for Fast

Connection Failover (FCF) to automatically connect to a

new primary database.

• Clients connect to the new primary database using an

Oracle Net connect descriptor configured for connect-time

failover.

Automating Client Failover

in a Data Guard Configuration

• Relocating database services to the new primary database

as part of a failover operation

• Notifying clients that the failure has occurred

• Redirecting clients to a new primary database

Summary

In this session, you should have learned how to:

• Understanding Data Guard Broker

• Configuring Data Guard Broker

• Configure client connectivity in a Data Guard configuration

• Implement failover procedures to automatically redirect

clients to a new primary database