Database Client Considerations

Event notification and database connection failover support is available to database clients connected to local database services when a broker-managed failover occurs.

For information about event notification and database connection failover support for global services, see the Oracle Database Global Data Services Concepts and Administration Guide.

After a failover, the broker publishes Fast Application Notification (FAN) events. These FAN events can be used in the following ways:

Applications can use FAN without programmatic changes if they use one of these Oracle integrated database clients: Oracle Database JDBC, Oracle Database Oracle Call Interface (OCI), Oracle Data Provider for .NET ( ODP.NET), or Universal Connection Pool for Java. These clients can be configured for Fast Connection Failover (FCF) to automatically connect to a new primary database after a failover.
JAVA applications can use FAN programmatically by using the JDBC FAN application programming interface to subscribe to FAN events and to execute event handling actions upon the receipt of an event.
FAN server-side callouts can be configured on the database tier.

FAN events are published using Oracle Notification Services (ONS) for all Oracle integrated database clients in Oracle Database 12c and later. In previous releases, OCI and ODP.NET clients receive FAN notifications via Oracle Advanced Queuing (AQ).

Note:

A single-instance database must be registered with Oracle Restart in order to publish FAN events via ONS.

Oracle Data Guard Specific FAN and FCF Configuration Requirements

There are configuration requirements that must be met in order to publish and properly handle FAN events generated as the result of a broker-managed failover.

These requirements are supplemental to those described in the documents previously referenced and in the following client-specific guides:

Oracle Net Configuration Requirements

For Fast Connection Failover (FCF) to occur, a client must be able to locate the new primary database after a failover.

This section describes how to configure an Oracle Net connect descriptor that meets this requirement.

The connect descriptor can be configured in one of two ways:

Configure the connect descriptor for connect-time failover. Add the primary database and each standby database to the address list. Set the CONNECT_TIMEOUT parameter to a small value to minimize the delay experienced if a network address is not available. Increase the value of this parameter if resource contention causes connection timeouts to occur during normal operation.
For example:
```
sales =
	  (DESCRIPTION= 
	    (FAILOVER=ON)
	    (CONNECT_TIMEOUT=5)
	    (ADDRESS_LIST=
	      (ADDRESS=(HOST=boston-scan)(PORT=1521))
	      (ADDRESS=(HOST=dallas-scan)(PORT=1521)))
	    (CONNECT_DATA=(SERVICE_NAME=sales)))
```
Configure the connect descriptor with a single network name that is registered with a global naming service such as DNS or LDAP. Create a trigger based on the DB_ROLE_CHANGE system event that changes the network address associated with the network name to the network address of the new primary database after a failover.
See Also:
- Oracle Database PL/SQL Language Reference for more information about the DB_ROLE_CHANGE system event

The connect descriptor must contain the SERVICE_NAME parameter in either case.

Database Service Configuration Requirements

Database services can be configured to be active in specific database roles on Oracle RAC databases and on single-instance databases managed by Oracle Restart.

The broker interacts with Oracle Clusterware or Oracle Restart to ensure that the appropriate database services are active and that the appropriate FAN events are published after a role change.

FAN events are always published through ONS. However, the event notifying a failover is only published for database services that have been configured to be active while the database is in the primary role on the new primary database.

Services that must be active in any given database role (primary, physical standby, logical standby, or snapshot standby) must be configured with the Server Control utility (SRVCTL) explicitly on each database where the service must be active.

In the following example commands, a service named PAYROLL is configured to be active in the PRIMARY role on the primary database NORTH. The service is then configured to be active in the PRIMARY role on the standby database SOUTH, so that it will be active on that database after a role transition. In these sample commands, the ellipse (...) signifies any other add service options you wish to supply.

Note:

The examples shown in this section do not necessarily show the specific attributes you might need to use in your own environment. The required attributes vary depending on your configuration (including whether your environment is Oracle RAC-based or single-instance). Refer to the appropriate Oracle RAC or Oracle Restart documentation for further information.

On primary database NORTH, execute the following:

srvctl add service –db NORTH –service PAYROLL –role PRIMARY ...

Configure services with the -drain_timeout attribute to set the amount of time to wait for the sessions drain prior to a switchover. If different services are configured with different values for -drain_timeout, broker will wait for the maximum configured value of the active services at the time switchover is initiated.

On standby database SOUTH, execute the following:

srvctl add service –db SOUTH –service PAYROLL –role PRIMARY ...

Services that are to be active while the database is in the physical standby role must also be created and started on the current primary database regardless of whether the service will be started on that database or not. This is to ensure that the service definition gets propagated to the physical standby database via the redo stream and thus allows for the service to be started on the physical standby database. The service can be started on the physical standby only after the redo generated by starting the service has been applied. It is important that all SRVCTL add service options be identical on all the databases so that the services behave the same way before and after a role change.

If all the databases do not have the same values, SRVCTL attempts to override the values, which will fail on the physical standby database because it is open read-only. In the following example, a service named sales is configured to be active in the PHYSICAL_STANDBY role on the primary database NORTH. It is then started and stopped on the primary database. It is then configured to be active in the PHYSICAL_STANDBY role on the physical standby database SOUTH.

Execute the following on primary database NORTH:

srvctl add service -db NORTH -service SALES -role PHYSICAL_STANDBY ...

srvctl start service –db NORTH –service SALES

srvctl stop service –db NORTH –service SALES

Execute the following on the physical standby database SOUTH:

srvctl add service -db SOUTH -service SALES -role PHYSICAL_STANDBY ...

If the broker now performs a switchover or failover, it automatically starts the SALES service on the correct database, based on the database's role.

The previous examples dealt with setting up only one service on a database. The following example shows you how to set up more than one service on a database and how using the broker ensures that the correct service starts on the correct database.

Suppose you have a primary database, BOSTON, and a standby database, CHICAGO. Issue the following SRVCTL commands so that both databases in the Data Guard configuration know about the two potential services for each database:

On BOSTON

srvctl add service -db BOSTON -service SALESRW  -role PRIMARY -policy AUTOMATIC
srvctl add service -db BOSTON  -service SALESRO  -role PHYSICAL_STANDBY -policy AUTOMATIC

On CHICAGO:

srvctl add service -db CHICAGO  -service SALESRW  -role PRIMARY -policy AUTOMATIC
srvctl add service -db CHICAGO  -service SALESRO  -role PHYSICAL_STANDBY -policy AUTOMATIC

To start things up initially, you must manually start the services on the correct node. You must also start and stop the SALESRO service on the primary so that it can be started on the standby. Issue the following SRVCTL commands:

On BOSTON:

srvctl start service -db BOSTON -service SALESRW
srvctl start service -db BOSTON -service SALESRO
srvctl stop service -db BOSTON -service SALESRO

On CHICAGO:

srvctl start service -db CHICAGO -service SALESRO

Now the correct services are running on the correct databases.

If the broker performs a switchover or failover, then it starts the service SALESRW or SALESRO based on the current role of the database. So SALESRW will start on CHICAGO (which is now the primary) and SALESRO will start on BOSTON (which is now the physical standby). The same thing happens if a shutdown and startup of either database occurs - the service that is started is the one that matches the role of the database being started.

Be aware that issuing the following manual commands on either database starts both the SALESRO and SALESRW services regardless of the roles specified in the SRVCTL command used to create the services. To start only the services specified for the current database role, add the -role qualifier to the srvctl start service command.

On BOSTON:

srvctl start service -db CHICAGO

On CHICAGO:

srvctl start service -db BOSTON

The SRVCTL command does not automatically take the database role into account, so any time you start a service manually, you must specify the name(s) of the service you want started or include the -role qualifier as part of the start service command as in the following example:

srvctl start service -db BOSTON -role

Note:

If the service has been configured to start automatically (-policy AUTOMATIC), then the service will automatically start only after a database role change.

Note:

In an Oracle Data Guard configuration, the SRVCTL -startoption for a standby database is always set to OPEN after a switchover.

ONS Configuration Requirements

If client-side ONS configuration is used, the client-side ONS configuration file must specify the hostname and port of the ONS daemon(s) of the primary database and each standby database.

If the client uses remote ONS subscription, the client must specify the hostname and port of the ONS daemon(s) of the primary database and each standby database.

Application Continuity

Application Continuity is an Oracle Database feature that enables rapid and nondisruptive replays of requests against the database after a recoverable error that made the database session unavailable.

Application Continuity is supported for Oracle Data Guard switchovers to physical standby databases. It is also supported for fast-start failover to physical standbys in maximum availability data protection mode. Note that primary and standby databases must be licensed for Oracle RAC or Oracle Active Data Guard in order to use Application Continuity.