Oracle RAC Services: Workload Management, Application Continuity, and TAF

Oracle RAC Services are the primary mechanism for workload management in a RAC cluster. Rather than connecting directly to an instance (which bypasses all intelligent routing), applications connect to a named service, and Oracle manages where that service is active. Combined with Application Continuity (AC), services provide seamless failover that is invisible to most application workloads.

Services Fundamentals

A service is a named workload bucket with the following attributes:

Preferred instances: Primary instances where the service is active.
Available instances: Failover instances where the service moves if a preferred instance fails.
Cardinality: SINGLETON (active on one instance at a time) or UNIFORM (active on all instances simultaneously).
Role: PRIMARY or PHYSICAL_STANDBY (for Active Data Guard integration).

# List all services in the cluster
srvctl status service -d ORCL

# Add a service for OLTP (preferred on instance 1, failover to instance 2)
srvctl add service \
  -d ORCL \
  -s OLTP_SVC \
  -preferred ORCL1 \
  -available ORCL2 \
  -cardinality SINGLETON \
  -pdb PDB1

# Add a uniform service for read workloads (active on all instances)
srvctl add service \
  -d ORCL \
  -s REPORT_SVC \
  -preferred "ORCL1,ORCL2" \
  -cardinality UNIFORM \
  -pdb PDB1

srvctl start service -d ORCL -s OLTP_SVC
srvctl start service -d ORCL -s REPORT_SVC

Service-Level Performance Attributes

Services can be annotated with performance and connection management attributes that affect how the Oracle Net listener and connection pool handle connections:

-- Modify service: set connection load balancing goal
EXECUTE DBMS_SERVICE.MODIFY_SERVICE(
  service_name         => 'OLTP_SVC',
  goal                 => DBMS_SERVICE.GOAL_SERVICE_TIME,  -- or GOAL_THROUGHPUT
  clb_goal             => DBMS_SERVICE.CLB_GOAL_SHORT,
  dtp                  => FALSE,   -- distributed transaction processing: FALSE for OLTP
  failover_method      => DBMS_SERVICE.FAILOVER_METHOD_BASIC,
  failover_type        => DBMS_SERVICE.FAILOVER_TYPE_SELECT,
  failover_retries     => 30,
  failover_delay       => 1
);

Connection Load Balancing Goal:

GOAL_SERVICE_TIME: Routes new connections to the instance with the shortest average response time. Best for OLTP where response latency matters.
GOAL_THROUGHPUT: Routes to the instance with the highest throughput. Better for batch workloads.

Transparent Application Failover (TAF)

TAF enables a client connection to automatically reconnect to a surviving instance after a node failure, and in SELECT failover mode, replays the cursor from the current position.

TAF is configured in the client’s tnsnames.ora:

OLTP_TAF =
  (DESCRIPTION =
    (LOAD_BALANCE = ON)
    (FAILOVER = ON)
    (ADDRESS = (PROTOCOL = TCP)(HOST = scan-hostname)(PORT = 1521))
    (CONNECT_DATA =
      (SERVICE_NAME = OLTP_SVC)
      (FAILOVER_MODE =
        (TYPE = SELECT)
        (METHOD = BASIC)
        (RETRIES = 30)
        (DELAY = 1))))

TAF Limitations

TAF handles:

Active SELECT cursors: replays from last fetched row.
Reconnection after instance failure.

TAF does not handle:

In-flight DML transactions (these are rolled back on the failed instance; the application receives an error and must retry).
PL/SQL session state (package variables, cursors opened in PL/SQL blocks).
DDL.

For DML transaction replay, Application Continuity is the superior solution.

Application Continuity (AC)

Application Continuity is a higher-level failover mechanism than TAF. When an instance fails mid-transaction, AC:

Reconnects to a surviving instance.
Replays all work from the beginning of the request (not just the current cursor).
Verifies that the replay had no side effects before returning to the application.

The application sees no error — from its perspective, the request completed normally with a slightly longer response time.

Prerequisites

Application must use Oracle JDBC with UCP (Universal Connection Pool) or ODP.NET.
Service must be configured with AC enabled.
Application must not have non-replayable side effects mid-request (e.g., explicit COMMIT inside a service call that also has non-idempotent external actions).

Enabling Application Continuity

# Enable AC on the service
srvctl modify service \
  -d ORCL \
  -s OLTP_SVC \
  -failovertype TRANSACTION \
  -commit_outcome TRUE \
  -replay_init_sleep 0 \
  -retention_timeout 86400 \
  -session_state_consistency DYNAMIC

// Java UCP configuration for Application Continuity
PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setConnectionFactoryClassName("oracle.jdbc.replay.OracleDataSourceImpl");
pds.setURL("jdbc:oracle:thin:@//scan-host:1521/OLTP_SVC");
pds.setUser("appuser");
pds.setPassword("password");
pds.setConnectionPoolName("oltp-pool");
pds.setInitialPoolSize(10);
pds.setMaxPoolSize(100);

Transparent Application Continuity (TAC)

TAC (Oracle 19c+) extends AC to work without any application-side JDBC configuration changes. TAC automatically identifies request boundaries and non-replayable operations:

srvctl modify service \
  -d ORCL \
  -s OLTP_SVC \
  -failovertype AUTO \
  -session_state_consistency AUTO

Drainable Connections and Planned Maintenance

Services support connection draining, enabling zero-downtime rolling patches:

Mark the service on the target instance as DRAINING.
Oracle notifies the connection pool (via ONS event) that this instance is about to go offline.
The pool stops routing new connections to the instance.
Existing connections complete their current work and close cleanly.
When all connections are drained, the instance can be patched.

# Relocate service for planned maintenance (drains connections first)
srvctl relocate service \
  -d ORCL \
  -s OLTP_SVC \
  -oldinst ORCL1 \
  -newinst ORCL2

DRCP: Database Resident Connection Pooling

For applications with many short-lived connections (web servers, microservices) that cannot use a full connection pool in the application tier, DRCP provides a server-side shared connection pool:

-- Start DRCP
EXECUTE DBMS_CONNECTION_POOL.START_POOL();

-- Configure pool size
EXECUTE DBMS_CONNECTION_POOL.CONFIGURE_POOL(
  pool_name     => 'SYS_DEFAULT_CONNECTION_POOL',
  minsize       => 4,
  maxsize       => 40,
  incrsize      => 2,
  session_cached_cursors => 20,
  inactivity_timeout => 300,
  max_think_time => 120,
  max_use_session => 500000,
  max_lifetime_session => 86400
);

Connect using DRCP by appending :POOLED to the service name in the connection string:

ORCL_DRCP =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = scan-host)(PORT = 1521))
    (CONNECT_DATA = (SERVICE_NAME = OLTP_SVC:POOLED)(SERVER = POOLED)))

Monitor DRCP pool utilisation:

SELECT pool_name,
       num_cbrok,
       minsize,
       maxsize,
       inuse_count,
       num_requests,
       num_misses
FROM dba_cpool_info;

A high num_misses rate means the pool is undersized or connection requests exceed pool capacity — increase maxsize.

Verifying Service Placement and ONS

Fast Application Notification (FAN) and Oracle Notification Service (ONS) are the signalling mechanisms that notify connection pools of service events (failover, planned maintenance). Verify ONS is configured:

# Check ONS configuration on each node
cat $ORACLE_BASE/../product/19.0.0/grid/opmn/conf/ons.config

# Test ONS connectivity from the application server
java -cp $ORACLE_HOME/lib/ons.jar oracle.ons.ONSTester -config ons.config

Without functional ONS, connection pools fall back to polling-based reconnection, significantly increasing failover time. Always validate ONS from application hosts as part of RAC deployment testing.

Services Fundamentals#

Service-Level Performance Attributes#

Transparent Application Failover (TAF)#

TAF Limitations#

Application Continuity (AC)#

Prerequisites#

Enabling Application Continuity#

Transparent Application Continuity (TAC)#

Drainable Connections and Planned Maintenance#

DRCP: Database Resident Connection Pooling#

Verifying Service Placement and ONS#