Using TAF with RAC

RAC provides near-continuous availability by hiding failures from end-user clients and application server clients. This provides continuous, uninterrupted data access. TAF reroutes application clients to an available database node in the cluster when the connected node fails. Application clients do not see error messages describing loss of service.


During the moment of failure, the database, the users and the transactions are in a specific state of operation, such as:
Retrieving data from the database

• Database has a connection via Oracle Net to the Instance on Node 1
• User connecting to the database has password and other user-authentication information
• The session has language and character set information that is specific to the Instance on which the user has established connection
• There are cursors open and in execution
• ‘SELECT’ cursors are open and partially scrolled by the user
• INSERT, UPDATE, and DELETE statements and PL/SQL procedures are being executed

Among the transactional statements, the following do not failover or are not protected when a node fails:

• PL/SQL server-side package variables .
• Global temporary tables .
• Effect of any ALTER SESSION statements .
• Applications not using OCI8 and above .
• Applications not using the JDBC thick driver .
• Transactional statements, i.e. Statements that include INSERT, UPDATE and DELETE operations .

Configuring the TAF option involves adding Oracle Net parameters to the tnsnames.ora and, when one of the participating nodes encounters failure, the use of parameter values to ascertain the next step in the failover process. The parameter that drives the TAF option is the FAILOVER_MODE under the CONNECT_DATA section of a connect descriptor.

The TAF option can be implemented in following three ways:

• Connect-Time Fail over and Client Load Balancing.

Oracle Net connects randomly to one of the listener addresses on nodes. If the Instance fails after the connection, Oracle Net fails over to the other node’s Instance, preserving any SELECT statements in progress.

• Retrying a Connection.

With the RETRIES and DELAY parameters as part of the fail over node sub parameter, the connections to the nodes are automatically retried to the number of times specified by the parameter. In this scenario the connection is retried 20 times with a delay of 15 seconds between every retry. Unlike the other option where one node in the cluster fails and the connection is reestablished on one of the other surviving nodes, under this option, the connection is retried on the same node and no backup node is defined as part of the configuration. Similarly there is no significance to the load-balancing parameter and has been set to off.

• Pre-Establishing a Connection.

Another implementation option available under the TAF configuration is to setup a pre-established connection to the backup or secondary Instance. One of the potential performance issues is the time required to re-establish a connection after the primary, or the first, node has failed to the backup or secondary node. This could be resolved by pre-establishing connections, which means that the initial and backup connections are explicitly specified. While there is a great advantage in pre-establishing the connection, this is not without any drawbacks. Pre-established connections consume resources.

With hardware level clustering and the proper usage of high availability solutions such as Oracle Real Application Clusters, users have a minimum impact when a system in the cluster is lost.