How to Set Server-Side Transparent Application Failover (TAF)

  • by

I have talked about how to set client-side Transparent Application Failover (TAF) pretty much. This time, we turn to server-side TAF.

There're 2 parts needs to be implemented in order to set server-side TAF in this post.

  1. Make a TAF Service
  2. Test the TAF Service

A. Make a TAF Service

1. Create a Service

Since server-side TAF is for failing over user connections to any other available instance of a RAC database, we should use Server Control (SRVCTL) to add a TAF service for it. In our case, we'd especially like to add a TAF service on a Pluggable Database (PDB), which is ORCLPDB.

[oracle@primary02 ~]$ srvctl add service -d orclcdb -s CRM -pdb ORCLPDB -preferred ORCLCDB1,ORCLCDB2 -failovertype select -failovermethod basic

In fact, there're 2 ways to add services to a PDB.

As you can see, the new service name is CRM and preferred instances are all included. Additionally, we choose the type of failover to SELECT level.

Please note that, we use uppercase service name and instance names in the above command to prevent any letter case problem.

2. Start the Service

We need to start the service before using it.

[oracle@primary02 ~]$ srvctl start service -d orclcdb -s crm
[oracle@primary02 ~]$ srvctl status service -d orclcdb -s crm
Service CRM is running on instance(s) ORCLCDB1,ORCLCDB2

The service is running.

3. Check Service Configuration

We may check the configuration of the service.

[oracle@primary01 ~]$ srvctl config service -d orclcdb -s crm
Service name: CRM
Server pool:
Cardinality: 2
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Global: false
Commit Outcome: false
Failover type: SELECT
Failover method: BASIC
Failover retries:
Failover delay:
Failover restore: NONE
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Pluggable database name: ORCLPDB
Hub service:
Maximum lag time: ANY
SQL Translation Profile:
Retention: 86400 seconds
Replay Initiation Time: 300 seconds
Drain timeout:
Stop option:
Session State Consistency: DYNAMIC
GSM Flags: 0
Service is enabled
Preferred instances: ORCLCDB1,ORCLCDB2
Available instances:
CSS critical: no
Service uses Java: false

B. Test the TAF Service

1. Add a TNS Name

We add an entry CRM in tnsnames.ora before we connect to the database.


2. Check Current Instance

We connect the database from a remote client.

C:\Users\edchen>sqlplus sh/sh@crm

Since we use Single Client Access Name (SCAN) to guide the connection to one of the available instance, we don't know where the connection go. So we need to check what instance we are in currently.

SQL> select instance_name from v$instance;


The current instance is ORCLCDB2.

3. Normal Query

We need to know how much time a normal would be in order to compare a failover query. Here we query 100,000 rows from a table.

SQL> set timing on;
SQL> select * from (select * from sales) where rownum <= 100000;
100000 rows selected.

Elapsed: 00:00:34.98

As we can see, the query took about 35 seconds to output all rows.

4. Failover Query

Now we trigger the query first, then shutdown node 2 to make the query fail over to the other instance and watch the behavior of the query.

SQL> select * from (select * from sales) where rownum <= 100000;

While the output is displaying, we power off node 2 completely to simulate a blackout.

After a while, the query seems stopped and hang about 15 seconds or so, then continue to output the result.

100000 rows selected.

Elapsed: 00:00:50.27

Eventually, the query consumed 50 seconds, a little longer than a normal run. The best thing is that the query is not interrupted.

5. Check Current Instance Again

Let's check what instance we are currently in.

SQL> select instance_name from v$instance;


We are in node 1. The TAF service is actually workable.

Leave a Reply

Your email address will not be published. Required fields are marked *