The document discusses Oracle Data Guard Broker and managing client connectivity in a Data Guard configuration. Some key points: - The Data Guard Broker automates configuration and monitoring of Data Guard, allowing management of an entire configuration from a single interface. - It supports primary and standby databases. Services like redo transport and log apply are managed. - Database services direct client connections to the correct database instance. A trigger ensures clients connect to the primary or standby as appropriate. - Role-based services started by the trigger allow applications to fail over automatically to a new primary without code changes, using Fast Application Notification.

1. Oracle Data Guard Broker
and
Managing Client Connectivity
By Mr. AKAL SINGH (OCM)

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

3. Data Guard Broker: Components
• Client-side:
– Oracle Enterprise Manager Grid Control
– DGMGRL (command-line interface)
• Server-side: Data Guard monitor
– DMON process
– Configuration files

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

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

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

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

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

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

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

11. Creating a Data Guard Broker Configuration

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

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

14. 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_HOMEdatabase
• Use DG_BROKER_CONFIG_FILEn to override the default
path name and file name.

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

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

17. Adding a Standby Database to the Configuration
DGMGRL> ADD DATABASE stdby AS
> CONNECT IDENTIFIER IS stdby;
Database “stdby" added
DGMGRL>

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

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

20. Managing Redo Transport Services
by Using DGMGRL
Specify database properties to manage redo transport services:
• DGConnectIdentifier
• LogXptMode
• LogShipping

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

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

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

24. Setting LogXptMode to ASYNC
Primary
database
transactions
RFS
MRP or
LSP
Archived redo
logs
ARC0
Standby
database
Standby
redo logs
OracleNet
(Real-time
apply)
Sets the ASYNC and NOAFFIRM
attributes of
LOG_ARCHIVE_DEST_n
Standby ack
LGWR
Online
redo
logs
Redo
buffer
LNSn

25. Setting LogXptMode to SYNC
LGWR
Primary
database
transactions
Online
redo
logs
RFS
MRP or
LSP
Archived redo
logs
ARC0
Standby
database
Standby
redo logs
OracleNet
(Real-time
apply)
Sets the SYNC and AFFIRM
attributes of
LOG_ARCHIVE_DEST_n
Standby ack
LNSn
Redo
buffer

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

27. Managing Client Connectivity

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

29. Understanding Client Connectivity:
Using Local Naming
Primary
database
Standby
database
OracleNet
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)))

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

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

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

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

34. 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);

35. Understanding Client Connectivity:
Using a Database Service
Primary
database
Standby
database
OracleNet
DG_PROD service
Using DG_PROD
Listener Listener

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

37. 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;
/

38. 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}]

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

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

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

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

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

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

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