Configuring Transparent Application Failover

Transparent Application Failover (TAF) is a client-side feature that allows for clients to reconnect to surviving databases in the event of a failure of a database instance. Notifications are used by the server to trigger TAF callbacks on the client-side.

TAF is configured using either client-side specified TNS connect string or using server-side service attributes. However, if both methods are used to configure TAF, the server-side service attributes will supersede the client-side settings. The server-side service attributes are the preferred way to set up TAF.

TAF can operate in one of two modes, Session Failover and Select Failover. Session Failover will re-create lost connections and sessions. Select Failover will replay queries that were in progress.

TAF automatically restores some or all of the following elements associated with active database connections.

- TAF automatically reestablishes the connection using the same connect string or an alternate connect string that you specify when configuring failover.

- TAF automatically logs a user in with the same user ID as was used prior to failure. If multiple users were using the connection, then TAF automatically logs them in as they attempt to process database commands.

- TAF allows applications that began fetching rows from a cursor before failover to continue fetching rows after failover. This is called "select" failover.

- Any active transactions are rolled back at the time of failure because TAF cannot preserve active transactions after failover.

- Server-side program variables, such as PL/SQL package states, are lost during failures; TAF cannot recover them.

Configuration on Client side:

 A backup connection can be pre-established. The initial and backup connections must be explicitly specified. In the following example, clients that use net service name taftest1 to connect to the listener on or-11 are also preconnected to or-12. If or-11 fails after the connection, Oracle Net fails over to or-12, preserving any SELECT statements in progress.

TAFTEST1 =
 (DESCRIPTION=
  (ADDRESS=
       (PROTOCOL=tcp) 
       (HOST=or-11) 
       (PORT=1521))
  (CONNECT_DATA=
     (SERVICE_NAME=rac)
     (INSTANCE_NAME=rac1)
     (FAILOVER_MODE=
       (BACKUP=TAFTEST2)
       (TYPE=select)
       (METHOD=preconnect))))

################################

TAFTEST2 =
 (DESCRIPTION=
  (ADDRESS=
       (PROTOCOL=tcp) 
       (HOST=or-12) 
       (PORT=1521))
  (CONNECT_DATA=
     (SERVICE_NAME=rac)
     (INSTANCE_NAME=rac2)
     (FAILOVER_MODE=
       (BACKUP=TAFTEST2)
       (TYPE=select)
       (METHOD=preconnect))))

TAF Verification

You can query FAILOVER_TYPE, FAILOVER_METHOD, and FAILED_OVER columns in the V$SESSION view to verify that TAF is correctly configured.

SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER, COUNT(*)
FROM V$SESSION
GROUP BY MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER;

TAF & RAC together

TAFTEST =
 (DESCRIPTION=
  (ADDRESS=
       (PROTOCOL=tcp)  
       (HOST=homecrs-scan.home.domain)  
       (PORT=1521)) 
  (CONNECT_DATA=
     (SERVICE_NAME=dbtst)
     (FAILOVER_MODE=
       (BACKUP=TAFTEST) 
       (TYPE=SELECT) 
       (METHOD=BASIC)))) 

Ref: 460982.1