Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









Overview of Transparent Application Failover (TAF)

Oracle RAC Cluster Tips by Burleson Consulting

This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters.  To get immediate access to the code depot of working RAC scripts, buy it directly from the publisher and save more than 30%.

Also see my notes on using TAF to guarantee availability.

The TAF function is controlled by processes external to the Oracle Database RAC cluster control. The cluster failover types and methods can be unique for each Oracle Net client. Under more complex environments, application code may have to be altered or modified to fully support TAF, using Oracle OCI calls. In its most basic form, TAF supports:

* Active Transactions: Any active, non-committed transaction (INSERT, UPDATE, or DELETE) is rolled back at the time of failure, because TAF cannot preserve active transactions after failover. The application will receive an error message until a rollback command is submitted.

* Client-Server Database Connections:  TAF automatically reestablishes the client-server database connection using the same connect string or an alternate connect string specified when configuring TAF in the tnsnames file.

* Executed Commands:  If a command was committed at the time of the connection failure and the command changed the state of the database, TAF will not reissue the command. If, by mistake, TAF reconnects in response to a command that may have changed the database, TAF issues an error message to the application.

* Open Cursors Used for Fetching:  TAF enables applications that began fetching rows from a cursor before the failover event to re-fetch the rows after failover. This type of failover is called select failover. TAF accomplishes this by re-executing the cursor select statement using the same working set, effectively retrieving the rows again. TAF verifies that the discarded rows are those that were returned initially, or it returns an error message to the application.

* Server side Program Variables:  Server side program variables, such as PL/SQL package states, are lost during failures. TAF cannot recover them. Making a call from the failover OCI callback functions to the server-side processes can initialize them.

* Users' Database Sessions:  TAF logs the users in with the same user IDs that were in use prior to failure. If multiple users were using the connection, TAF automatically logs them in as they attempt to process database commands. Unfortunately, TAF cannot automatically restore non-persistent session properties. These properties can, however, be restored by invoking an OCI callback function that notifies the calling transaction of the switchover and requests the non-persistent session properties.

In a nutshell, the above means that at the time of failover, in-progress queries are reissued and processed from the beginning. Rows already fetched are discarded. All of this discarding of rows and re-fetching can delay the completion of the original transaction. However, TAF can also be configured to issue two connections at a time, one to the main instance and one to the standby instance. This speeds the processing by eliminating the reconnection penalty. DDL operations are not reissued. Committed transactions are not reissued.

Uncommitted INSERT, UPDATE and DELETE commands are rolled back and must be resubmitted after reconnection. Again, use of the OCI packages should be utilized to have the DML operations reissued.

The Oracle Net process carries out TAF functionality. The failover is configured in the tnsnames file. The TAF settings are placed in the net service name area, within the connect_data section of the tnsnames, using the failover_mode and instance_role parameters.


Subparameter Descriptions


Used to set a different net service name for backup instance connections. A backup should be specified when using preconnect to pre-establish connections.


Used to specify the type of connection failover. There are three types of Oracle Net failover functionality available to Oracle Call Interface (OCI) applications:

* session: Used to set to failover the session. When a user's connection is lost, a new session is automatically created for the user on the backup. This type of failover will not recover selects. 

* select: Used to enable users with open cursors (selects) to continue fetching on them after failure. It should be noted that this mode involves some overhead on the client side during normal select operations. 

* none: This setting is the default. With none, no failover functionality is provided. If the goal is to prevent failover, use the none setting.



This is used to determine how failover occurs from the primary node to the backup node:


* basic: Set this mode to establish connections only at failover time. Since no preconnection is done, basic requires virtually no work on the backup server until failover occurs.

* preconnect: Set this mode to pre-established connections to a backup server. The preconnect setting provides for faster failover but does require that the backup instance be capable of supporting all connections from all supported instances.



This sets the number of times that the server will attempt to connect after a failover. With DELAY specified but RETRIES not specified, RETRIES will default to five retry attempts.


This specifies the number of seconds between connection attempts. When RETRIES is specified and DELAY is not, DELAY defaults to one second.

Table 10.1: fail_over Mode Options

Setting load_balance=YES instructs Net to progress through the list of listener addresses in a random sequence, balancing the load on the various listeners. When set to OFF, load_balance instructs Net to try the addresses sequentially until one succeeds. This parameter must be correctly coded in the net service name or connect descriptor. By default, this parameter is set to ON for description_list.  Load balancing can be specified for an address_list, associated with a set of addresses or set descriptions. If address_list is used, the load_balance=YES should be within the (address_list=) portion.  If address_list is not used, the load_balance=YES should be within the DESCRIPTION clause.

failover=ON is the default for address_list, description_list and the set of description; therefore, it does not have to be specified.  This only applies for connect time failover not transparent application failover (TAF).  

The failover_mode parameter must be included in the connect_data portion of a net_service_name. There is no BACKUP=failover in failover_mode=. This implies (failover_mode=(TYPE=SELECT) (METHOD=BASIC) (BACKUP=failover)), meaning whenever failover occurs, the connected session will failover to the net_service_name failover again.  A backup should be specified when using PRECONNECT to pre-establish connections.

If it is desired to have remote instances registered with the listener, even if the listener is using port 1521, local_listener still needs to be in the init.ora file. Otherwise, with remote_listener="<remote_listener>" alone, the remote instances will not be registered with the listener, and there will be no server-side listener connection load balancing.  This is due to bug 2194549 that is fixed in 10g.

If the configuration is not using the default port 1521, the local_listener parameter in the initialization file is required. If the hostname output is the interconnect IP address as opposed to the public Ethernet IP address, the PMON process will register the service and instance with the hostname's listener. In this case, the local_listener parameter should be set to instruct the PMON to register the service and instance with the public Ethernet IP address listener.

The following script demonstrates the initialization parameters that would be set for the example server setup.  Both nodes? init.ora file would have the following parameters:


The TAF parameters must be manually added to the tnsnames file, since the network configuration assistant (NETCA) cannot configure them. Once configured, Oracle Net will failover the connection, transparently to the user in many cases, with the exceptions noted in the list of failover objects above.

In order to configure TAF, the static service information must be removed in the <sid>_list_<listener_name> entry from the listener.ora, allowing the instance to self-register.  This is known as Dynamic Service Registration and has been available since Oracle8i. In addition, the global_dbname parameter must be removed from the tnsnames file or TAF will be disabled.


This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters, Rampant TechPress, by Mike Ault and Madhu Tumma.

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational