How To Configure Client Failover For Data Guard Connections Using Database Services.pdf

How To Configure Client Failover for
Data Guard Connections Using Database
Services
FAN vs TAF vs TAC vs AC
07/07/2025 Written by: ALIREZA KAMRANI
Introduction:
Oracle RAC provides scalability and high availability for the Oracle Database. If one server (RAC
node) fails or is taken offline for maintenance, the database is still accessible through the
additional nodes. However, what happens to client sessions that are executing some work,
whether reading or changing data, when maintenance begins? That work will be interrupted
and need to be executed again by the end-user or the application unless you implement
draining and enable Application Continuity or Transparent Application Continuity.
Oracle RAC provides high availability for the Oracle database. From the application perspective,
Fast Application Notification (FAN) allows relocating sessions to the running node, Draining
enables active sessions to finish their requests within a predefined drain timeout, and
Application Continuity replays interrupted requests for the sessions that did not drain (=finish
executing their requests). All this is done transparently to the end-user and applications.
Application Continuity (AC) is an Oracle Database feature that enables the seamless and rapid
replay of an in-flight request against the database following a recoverable error that makes the

database session unusable. Its primary goal is to ensure that the interruption appears to the
end-user as nothing more than a delay in request processing. AC works by completely
reconstructing the database session after an outage, including all states, cursors, variables, and
the last transaction (if any). This effectively masks disruptions caused by planned maintenance
(e.g., patching, configuration changes) or unplanned outages (e.g., network errors, instance
failures).
Transparent Application Continuity (TAC), introduced with Oracle Database 18c, is an extension
or mode of AC. TAC transparently tracks and records session and transactional state, enabling
the recovery of a database session after recoverable outages. The key characteristic of TAC is its
ability to operate without requiring any application code changes or specific knowledge of the
application by the database administrator (DBA). This transparency is achieved through a state-
tracking infrastructure that categorizes session state usage.
Both AC and TAC can be used with Oracle Real Application Clusters (RAC), Oracle RAC One Node,
Oracle Active Data Guard, and Oracle Autonomous Database (both shared and dedicated
infrastructure). These features enhance the fault tolerance of systems and applications by
masking database outages and recovering in-flight work that would otherwise be lost.
Without AC/TAC, database outages cause significant problems for applications. Applications
receive error messages, users are left uncertain about the status of their transactions (e.g.,
money transfers, flight reservations, orders), and middleware servers might even need
restarting to handle the surge of login requests post-outage. This leads to both end-user
dissatisfaction and operational inefficiency.
AC and TAC enable the Oracle Database, Oracle drivers, and Oracle connection pools to
collaborate, safely and reliably masking many planned and unplanned outages. By automatically
handling recoverable errors, they improve the end-user experience and reduce the need for
application developers to write complex error-handling code. This boosts developer productivity
and aims for uninterrupted application operation.
The evolution from Oracle’s basic failover mechanisms (like TAF – Transparent Application
Failover) to AC and then TAC reflects a strategic shift towards making high availability
increasingly transparent and reducing application-specific coding dependencies. TAF (pre-12c)
had significant limitations, especially around DML operations and session state management. AC
(12c) addressed DML replay but required awareness of connection pool usage and request
boundaries. TAC (18c+) further reduced complexity by automating state tracking and boundary
detection. This progression shows Oracle recognized the adoption barriers of earlier solutions
and prioritized ease of use alongside capability. Consequently, TAC has become Oracle’s

preferred solution for modern applications, especially in cloud and Autonomous Database
environments , while AC remains relevant for specific legacy systems or customization needs.
AC and TAC extend Oracle’s MAA principles to the application tier. MAA is a set of best
practices, configurations, and architectural blueprints designed to achieve zero data loss and
zero application downtime goals. AC and TAC contribute to these goals by recovering in-flight
transactions and the application stack.
These features work in conjunction with other Oracle HA solutions like RAC, Data Guard, and
Fast Application Notification (FAN) to form the building blocks for continuous availability. The
MAA framework aims to keep applications continuously available by hiding planned and
unplanned events, as well as load imbalances at the database tier. AC and TAC are integral parts
of this architecture, minimizing the impact of database outages on the application.
The Replay Process: How AC/TAC maintains and Recovers Sessions
The working mechanism of AC and TAC involves the following steps when a recoverable error is
detected:
1. Error Detection: The system identifies a recoverable error (e.g., network interruption,
temporary instance failure) that renders the session unusable.
2. New Session Establishment: A new database session is established on another available
database instance.
3. Session State Restoration: The state of the original session before the interruption (non-
transactional state, variables, PL/SQL package states, etc.) is reconstructed in the new
session. This is managed through service parameters
like FAILOVER_RESTORE and SESSION_STATE_CONSISTENCY, and mechanisms like
Database Templates in 23ai.
4. Replay of Database Calls: The database calls (SQL queries, DML operations) made from
the beginning of the interrupted request are executed sequentially in the new session.
5. Consistency Check and Idempotence: During replay, data consistency is checked. The
Transaction Guard mechanism ensures that the transaction is committed only once
(idempotence), especially if the interruption occurred during the COMMIT operation.
6. Continuation or Error: If the replay is successful, the application perceives the
interruption merely as a delay and continues from where it left off. However, if data

inconsistency is detected during replay (e.g., a replayed query returns different results)
or an unrecoverable state is encountered, the replay is rejected, and the application
receives the original error. Unrecoverable errors (e.g., invalid data input) are never
replayed.
This process ensures that the user is unaffected by the interruption and the transaction is either
completed safely or the original error state is accurately reported.
Transactional State and Idempotence
AC and TAC aim to preserve the integrity of the last transaction during the replay of an
interrupted request. This becomes critical, especially when an interruption occurs after
the COMMIT command is sent but before the acknowledgment is received. This is
where Transaction Guard (TG) comes into play.
Transaction Guard (TG) determines the definitive outcome (COMMIT_OUTCOME) of the
transaction, preventing the same transaction from being committed multiple times during
replay.
AC and TAC rely on this idempotence guarantee provided by TG to perform the replay safely.
How To Configure Client Failover for Data Guard Connections Using Database Services
The best approach for hiding planned maintenance activities from your applications is to
transparently drain work from each database workload location prior to the maintenance
window for that workload location. Oracle’s connection pools and mid-tiers, including the
WebLogic Server, Universal Connection Pool (UCP), OCI Session pool and ODP.NET Unmanaged
Provider are Fast Application Notification (FAN) aware and therefore are notified before
database services are scheduled to move to allow graceful draining of work before
maintenance. FAN notification automatically triggers closing idle connections, opening new
connections in the new service location, and allows a configurable time for active work to
complete in the soon-to-be-shutdown service location. The major third-party JDBC mid-tiers,
such as IBM WebSphere, allow for the same behavior when configured with UCP. For JDBC-
based applications that cannot use UCP, Oracle provides solutions using Oracle Drivers and
connection tests.

In order to hide unplanned outages resulting from a component or communication failure
Oracle provides:
Notification - FAN is the first step to hiding outages. FAN notifies clients and breaks them out of
their current network wait when an outage occurs. This avoids stalling applications for long
network waits. Importantly, FAN also invokes rebalancing of sessions when services are
available again.
Recovery – After the client is notified, Application Continuity (AC) or Transparent Application
Continuity (TAC), re-establish a connection to a new workload location (which may be to the
same or another instance in the Real Application Clusters (RAC) case, or a standby site in the
Data Guard case) and replays in-flight (uncommitted) work when possible. By replaying in-flight
work on the new location, the application can usually continue executing without knowing that
any failure happened.
AC or TAC also executes during planned maintenance: for those sessions that do not drain
(complete their current database operation) during the allocated drain interval.
In a Data Guard environment primary database is open in read write mode and the standby
database in read only mode for reporting purpose.
This document describes how to setup clients to connect to Data Guard databases (primary and
standby) and configure automatic client failover such that in case there is role change due to
switchover or failover, the client connections
should still be valid i.e. the clients that need to connect to read only standby should always
connect to the current standby irrespective of which database in the Data Guard configuration
is currently in standby role and same for primary
connections.
Oracle Application Continuity hides database interruptions from end-users and applications.
However, SQL*Plus is usually not your real application that will be used in production. Also,
SQL*Plus is not a pooled application, and it’s recommended to use Connection Pools for
Application Continuity.
This goal is achieved via database services.
CONNECT USING SERVICES

Services provide transparency for the underlying ATP-D infrastructure. FAN, connection data,
Transparent Application Continuity (TAC), Application Continuity (AC), switchover, consumer
groups and many other features and operations are predicated on the use of services. The
services you use also define the primary or standby role in the underlying Data Guard
environment.
Oracle’s Autonomous Database Transaction Processing Dedicated (ATP-D) offers five
preconfigured services to choose from. All provide FAN and draining. TPURGENT and TP have
TAC enabled by default in the ATP-D environment. An API is available to change the TAC or AC
settings on all preconfigured services.
CONFIGURE CONNECTION STRING/URL FOR HIGH AVAILABILITY
Oracle recommends the Connection String/URL configuration shown below when connecting to
the Oracle Autonomous Database. Connect strings embedded in the Oracle-supplied wallet are
configured in this fashion. Do not use Easy Connect Naming on the client because EZCONNECT
has no high-availability capabilities.
Note that the standby-scan specified below refers to the SCAN address available on the standby
site specified in the Active Data Guard configuration. The driver attempts to connect to the

primary site first, and if the service is not available, then attempts to connect to the service at
the standby. Once the connection to the service is made, at whichever site, the Oracle driver
version 12.2 and later remembers the TNS address list that offers that service and gives this site
priority.
To help in choosing the service for batch work:
HIGH: Queries run with a Degree of Parallelism equal to CPU_COUNT. There is a limit of three
concurrent queries after which statement queuing occurs.
MEDIUM: Queries run with a Degree of Parallelism of four. The maximum number of queries
that can run simultaneously is (CPU_COUNT*1.25).
LOW: Queries run serially. Queueing starts when concurrent queries exceed (2*CPU_COUNT).
Use this Connection String for ALL Oracle drivers’ version 12.2 or higher:
Alias (or URL) =
(DESCRIPTION =
(CONNECT_TIMEOUT=
90)(RETRY_COUNT=50)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521)))
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=standby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = ATP-D SERVICE)))
Use the following for JDBC connections using Oracle driver version 12.1 or earlier
Alias (or URL) =
(DESCRIPTION =

(CONNECT_TIMEOUT= 15)(RETRY_COUNT=50)(RETRY_DELAY=3)
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521)))
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=standby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = ATP-D SERVICE)))
USE FAST APPLICATION NOTIFICATION
FAN provides immediate notification to an application in the event of an outage or resumption
of service.
Without FAN, applications can hang on TCP/IP timeout following hardware and network failures,
and omit to rebalance when resources resume.
All Oracle pools and all Oracle application servers use FAN. Third-party JAVA application servers
can use UCP to enable FAN.
No application changes are required to use FAN. These are configuration changes only.
For continuous service during planned maintenance, use FAN with:
• Oracle pools or
• UCP with third-party JDBC application servers or
• The latest Oracle client drivers
For continuous service during unplanned outages, use FAN with
• Application Continuity or
• Transparent Application Continuity
USE RECOMMENDED APPLICATION PRACTICES TO ALLOW DRAINING

Best practice for application usage is to check out connections for the time that they are
needed, and then check them back in to the pool when the current action is complete. This is
important to achieve good performance, for the rebalancing of work at runtime, and during
maintenance windows for draining the work. Refer to the statistics section Understanding your
protection level when using TAC or AC for an indication of how well your application follows this
practice.
Oracle recommends using a FAN-aware Oracle connection pool for hiding planned maintenance.
There is no impact to users when your application uses an Oracle Pool with FAN and returns
connections to the pool between requests. You do not need to make any application changes to
use FAN.
When an Oracle connection pool receives the FAN event for planned downtime, it marks all
connections at the instance to be drained. Immediately, checked-in connections are closed so
that they are not re-used. As in-use connections are returned to the pool they are closed. This
allows all connections to be closed gracefully over time.
If you are using a third-party, Java-based application server, then the most effective method to
achieve draining and failover is to replace the pooled data source with UCP. Many application
servers support this approach, including Oracle WebLogic Server, IBM WebSphere, IBM Liberty,
Apache Tomcat, Red Hat WildFly (JBoss), Spring, Hibernate, and others. White papers from
Oracle and other providers, such as IBM, describe how to use UCP with these application
servers. Using UCP as the data source allows UCP features such as Fast Connection Failover,
Runtime Load Balancing, Application Continuity and Transparent Application Continuity to be
used with full certification.
FAN Coverage
FAN events are integrated with:
• Oracle Fusion Middleware and Oracle WebLogic Server
• Oracle Data Guard Broker
• Oracle JDBC Universal Connection Pool or Driver for both JDBC thin and Oracle Call Interface
(OCI) interfaces
• ODP.NET Connection Pool for Unmanaged and Managed Providers
• Oracle Tuxedo
• SQL*Plus
• Oracle Database drivers for languages such as Python, Node.js and PHP

• Global Data Services
• Third party JDBC application servers using Oracle JDBC Universal Connection Pool
• Listeners
To enable FAN in the client:
Use the TNS alias or URL shown in the preceding discussion. This connection string is used to
auto-configure the Oracle Notification Service (ONS) subscription at the client for FAN-event
receipt when using an Oracle Database 12c or later client driver. For older drivers, refer to the
FAN white paper in the Appendix for configuration details. ONS provides a secure
communication path between the database tier and the client-tier allowing the client to be
notified of service availability (components stopping or starting) as well as runtime load
balancing advice for better work placement during normal operation.
Depending on the client, enable FAN in the application configuration properties as follows
Universal Connection Pool or JDBC thin driver (starting 12.2)
Set the property FastConnectionFailoverEnabled
WebLogic Active GridLink for Oracle RAC
FAN and Fast Connection Failover are enabled by default
Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss),
JDBC Applications
Use Universal Connection Pool as a connection pool replacement
ODP.Net clients (Managed and Unmanaged Providers)
Set “HA events = true;pooling=true” in the connect string if using ODP.Net 12.1 or
earlier
Oracle Call Interface (OCI) clients and OCI-based drivers
Oracle Call Interface (OCI) clients without native settings can use an oraacces.xml file and
set events to true
Python, Node.js and PHP have native options. In Python and Node.js you can set an
events mode when creating a connection pool. In PHP, edit php.ini add the entry oci8.events=on
SQL*Plus enables FAN by default

In the ATP-D environment ONS offers an optional TLS (wallet-based) authentication. Depending
upon the type of application (JDBC or Oracle Call Interface), the wallet configuration must follow
particular rules
Transparent Application Continuity Coverage
Transparent Application Continuity for Oracle Autonomous Database supports the following
clients:
It is strongly recommended to use the latest client drivers. Oracle Database 19c client drivers
and later provide full support for TAC.
• Oracle JDBC Replay Driver 18c or later. This is a JDBC driver feature provided with Oracle
Database 18c for Application Continuity
• Oracle Universal Connection Pool (UCP) 18c or later with Oracle JDBC Replay Driver 18c or
later.
• Oracle WebLogic Server Active GridLink, or third-party JDBC application servers using UCP
with Oracle JDBC Replay Driver 18c or later
• Java connection pools or standalone Java applications using Oracle JDBC Replay Driver 18c or
later
• Oracle Call Interface Session Pool 19c or later
• SQL*Plus 19c (19.3) or later
• ODP.NET pooled, Unmanaged Driver 18c or later (“Pooling=true” default in 12.2 and
later)
• Oracle Call Interface based applications using 19c OCI driver or later
How to handle these requirements based on database version?
In 11gR2, we have the concept of role-based database services. For Data Guard environments
running older release, this is achieved via a database startup trigger.
Note: Starting from 12cR1 (12.1), you can consider using Global Data Services to seamlessly
manage client connections for dataguard or Golden Gate replicated database

Solution
Pre 11.2 Configuration:
+ On the current primary, create 2 services, one to connect to the primary (prim_db) and
another (stby_db) to connect to the read only standby:
SQL> exec dbms_service.create_service('prim_db','prim_db');
SQL> exec dbms_service.create_service('stby_db','stby_db');
+ On the current primary, start the service that is needed to connect to primary:
SQL> exec dbms_service.start_service('prim_db');
+ Now, on the current primary, create the trigger to manage these services accordingly:
CREATE OR REPLACE TRIGGER startDgServices after startup on database
DECLARE
db_role VARCHAR(30);
db_open_mode VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE, OPEN_MODE INTO db_role, db_open_mode FROM V$DATABASE;
IF db_role = 'PRIMARY' THEN DBMS_SERVICE.START_SERVICE('prim_db'); END IF;
IF db_role = 'PHYSICAL STANDBY' AND db_open_mode LIKE 'READ ONLY%' THEN
DBMS_SERVICE.START_SERVICE('stby_db'); END IF;
END;
/
+ Note down the current online redo log sequence on primary and switch the current logfile:
SQL> select thread#, sequence# from v$log where status = 'CURRENT';
SQL> alter system archive log current;

Ensure that the archive with sequence# which was shown as current is shipped and applied on
standby. This ensures that the redo from CREATE TRIGGER command is applied on standby.
Now, shutdown and startup the standby database to make the trigger take effect:
SQL> shut immediate;
SQL> startup;
+ Configure client TNSNAMES.ORA entry. In below example PRIM_DB should be used by clients
that need to connect to primary database.
STBY_DB should be used by clients that need to access the read only standby database:
PRIM_DB =
(DESCRIPTION =
(ADDRESS_LIST =
(FAILOVER = ON)
(LOAD_BALANCE = OFF)
(ADDRESS = (PROTOCOL = TCP)(HOST = primary.oracle.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = standby.oracle.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = prim_db)
)
)
STBY_DB =
(DESCRIPTION =
(ADDRESS_LIST =

(FAILOVER = ON)
)
(CONNECT_DATA =
(SERVICE_NAME = stby_db)
)
)
Configuration in 11.2 or later release:
We will be using role-based database services introduced in 11.2. To use role-based services,
Oracle Clusterware must be installed and active on the primary and standby sites for both single
instance (using Oracle Restart) and Oracle RAC databases.
+ On the primary and standby hosts create the service (prim_db) that the clients will use to
connect to the primary database.
The service should be created such that it is associated with and runs on the database when it
is in the ‘PRIMARY’ database role:
On primary:
[oracle@vmOraLinux ~]$ srvctl add service -d ora12c -s prim_db -l PRIMARY -e SESSION -m
BASIC -w 10 -z 10
On standby:
[oracle@vmOraLinux ~]$ srvctl add service -d stby12c -s prim_db -l PRIMARY -e SESSION -m
BASIC -w 10 -z 10
+ Start the primary database service (prim_db) on the current primary:

[oracle@vmOraLinux admin]$ srvctl start service -d ora12c -s prim_db
+ Next, on the primary and standby hosts create the service (stby_db) that the clients will use to
connect to the read only standby database.
The service should be created such that it is associated with and runs on the database when it is
in the ‘PHYSICAL_STANDBY’ database role:
On primary:
[oracle@vmOraLinux ~]$ srvctl add service -d ora12c -s stby_db -l PHYSICAL_STANDBY -e
SESSION -m BASIC -w 10 -z 10
On standby:
[oracle@vmOraLinux ~]$ srvctl add service -d stby12c -s stby_db -l PHYSICAL_STANDBY -e
SESSION -m BASIC -w 10 -z 10
+ Now, start the standby service (stby_db) on standby host:
[oracle@vmOraLinux ~]$ srvctl start service -d stby12c -s stby_db
If you get below error when trying to start the service on standby:
PRCD-1084 : Failed to start service stby_db
PRCR-1079 : Failed to start resource ora.stby12c.stby_db.svc
CRS-5017: The resource action "ora.stby12c.stby_db.svc start" encountered the following error:
ORA-44317: database open read-only
ORA-06512: at "SYS.DBMS_SERVICE", line 478
ORA-06512: at "SYS.DBMS_SERVICE", line 229
ORA-06512: at line 1

Then as workaroud, follow below steps:
a. Start the service on primary instead:
[oracle@vmOraLinux ~]$ srvctl start service -d ora12c -s stby_db
b. Perform a few log switches on primary and allow standby to catch up.
c. Now, the service should start on standby:
[oracle@vmOraLinux ~]$ srvctl start service -d stby12c -s stby_db
d. Stop the service on primary:
[oracle@vmOraLinux ~]$ srvctl stop service -d ora12c -s stby_db
+ Configure client TNSNAMES.ORA entry. In below example PRIM_DB should be used by clients
that need to connect to primary database.
STBY_DB should be used by clients that need to access the read only standby database:
PRIM_DB =
(DESCRIPTION =
(ADDRESS_LIST =
(FAILOVER = ON)
)
(CONNECT_DATA =
(SERVICE_NAME = prim_db)
)
)
STBY_DB =

(DESCRIPTION =
(ADDRESS_LIST =
(FAILOVER = ON)
)
(CONNECT_DATA =
(SERVICE_NAME = stby_db)
)
)
CONCLUSION
The Oracle Autonomous Database is configured and managed for high availability on your
behalf. No additional configuration or management is required by you.
There are a few simple steps to achieving Continuous Availability for your applications:
• Select the ATP-D service that is appropriate for your SLA’s
• Configure Fast Application Notification (FAN)

• Use the recommended connection string for your applications
• Use application best practices to optimize for draining
• Use Transparent Application Continuity or Application Continuity for continuous service
By following these five simple steps, planned maintenance activities will no longer require
outages and unplanned events will rarely result in failed transactions and interruptions to
service.
More info:
https://www.oracle.com/docs/tech/database/continuous-service-for-apps-on-atpd.pdf

How To Configure Client Failover For Data Guard Connections Using Database Services.pdf

More Related Content

Similar to How To Configure Client Failover For Data Guard Connections Using Database Services.pdf (20)

More from Alireza Kamrani (20)

Recently uploaded (20)

How To Configure Client Failover For Data Guard Connections Using Database Services.pdf