Transparent Application Failover (TAF) Feature

Transparent Application Failover:

After an Oracle RAC node crashes - usually from a hardware failure, all new application transactions are automatically rerouted to a specified backup node. The challenge in rerouting is to not lose the transactions that were in "in flight" at the exact moment of the crash. One of the requirements of continuous availability is the ability to restart in-flight application transactions, allowing a failed node to resume processing on another server without interruption.

TAF feature is a run time failover for high availability environments. It enables client applications to automatically reconnect to the database if the connection fails and optionally resume a select statement that was in progress. The reconnection happens automatically from within the Oracle Call Interface (OCI) library.

The TAF architecture offers the ability to restart transactions at either the transaction (SELECT) or session level:

SELECT failover: With SELECT failover, Oracle Net keeps track of all SELECT statements issued during the transaction, tracking how many rows have been fetched back to the client for each cursor associated with a SELECT statement. If the connection to the instance is not lost, Oracle Net establishes a connection to another Oracle RAC node and re-executes the SELECT statements.

SESSION failover: When the connection to an instance is lost, SESSION failover results only in the establishment of a new connection to another Oracle RAC node; any work in progress is lost. SESSION failover is ideal for OLTP systems, where the transactions are small.

Failover Methods:
BASIC failover: In this approach, the application connects to a backup node only after the primary connection fails. This approach has low overhead, but the end user experiences a delay while the new connection is created.

PRECONNECT failover: In this approach, the application simultaneously connects to both a primary and backup node. This offers fast failover, because a pre-spawned connection is ready to use. But the extra connection adds everyday overhead by duplicating connections.

• Make sure that instances are running:

crs_stat -t
If either of database is offline, then start the instance
srvctl start instance -d RACDB -i RAC1

• Create a service: Before you can use TAF, you need to create an application service using EM or DBMS_SERVICE package.

EM -> Click Maintenance -> Cluster Managed Database Services -> Create Service

exec dbms_service.modify_service (service_name => SERV1,
failover_method => dbms_service.failover_method_basic,
failover_type => dbms_service.failover_type_select,
failover_retries =>
.....)

• Before you can start using your service, add corresponding entry in tnsnames.ora file.

RACDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = RAC2_VIP) (PORT=1521))
(ADDRESS = (PROTOCOL = TCP) (HOST = RAC1_VIP) (PORT=1521))
(FAILOVER = ON)
(LOAD_BALANCE = YES)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = SERV1)
)
)

TAF allows DBA to configure the type and method of failover for each Oracle Net Client.

Limitations of TAF:
The following types of transactions do not automatically failover and must be restarted by TAF:
Transactional statements: Transactions invloving INSERT, UPDATE, or DELETE statements are not supported by TAF
ALTER SESSION statements. ALTER SESSION and SQL*Plus SET statements do not failover

The following do not failover and cannot be restarted:
Temporary objects. Transactions using temporary segments in the TEMP tablespace and global temporary tables do not failover.

Refrence: Oracle Video Presentation by Ritesh Das, Oracle India.