Configuring OPS/RAC net service for failover

There are three files to be configured: listener.ora, tnsnames.ora,

and sqlnet.ora. You can use netasst to configure them graphically, or
you can just edit these files manually if you are confident with
OPS/RAC. We directly edited these files, since it is faster to do so.
You must manually edit the files to implement a new listener for
failover and netasst does not allow using the same port number for
another listener.
Implementing failover does not allow the use of static service
configuration parameters in the listener.ora file. Therefore, in order
to implement OPS/RAC failover, an additional listener must be
specified on each node in the listener.ora file without service
registration information. Edit the sqlnet.ora file to ensure that
tnsnames.ora is used to resolve a net service name.

Client load balance

When you set load_balance=on in tnsnames.ora, OPS/RAC will

balance the load over the list of listener addresses by picking one at
random.
There are two different kinds of OPS/RAC failovers: connection-time
failover (CTF) and transparent application failover (TAF). For TAF,
there are several different configurations using TYPE and METHOD
parameters.

Connection-time failover (CTF)

Connection-time failover refers to a client attempting to connect to a

second listener when the attempt to connect to the first listener fails.
To implement this, create a new net service name with the database
name as its identifier, such as opswas, instead of opshp1 or opshp2.
Put the address information of all nodes in the cluster in this newly
created global net service name.
Use one of two options: FAILOVER=ON
Setting this means: try each address in order until one succeeds.
FAILOVER=ON LOAD_BALANCE=ON
Setting this means: try each address randomly until one succeeds.
WebSphere® works with either setting.
 Example 12-8 is a sample tnsnames.ora file using these OPS/RAC
connection-time failover options.
Example 12-8 Sample OPS/RAC CTF tnsnames.ora file

WASOPSCTF.somecorp.com=
(description=
(load_balance=on)
(failover=on)
(address=
(protocol=tcp)
(host=idops1)
(port=1521))
(address=
(protocol=tcp)
(host=idops2)
(port=1521))
(connect_data=
(service_name=WASOPSCTF.somecorp.com))))

Transparent application failover (TAF)

Transparent application failover enables an application to

automatically reconnect to a database if the connection is broken.
Active transactions roll back, and the new database connection is
identical to the original one no matter how the connection is lost.
Implementing transparent application failover requires you to
manually configure tnsnames.ora with the specification of a primary
node, a backup node, failover type, and failover method. You can
also combine OPS/RAC CTF with OPS/RAC TAF. As shown in Table 12-
1, there are 12 configurations (2 CTF x 3 TYPE x 2 METHOD) for the
OPS/RAC TAF implementations.
Table 12-1

CTF TYPE METHOD

FAILOVER=ON SESSIO BASIC

N

FAILOVER=ON SELEC PRECONNE

LOAD_BALANCE=ON T CT

NONE

Combinations of OPS/RAC/TAF failover configuration

implementations
 The parameter TYPE specifies the type of failover. This is a required
parameter for the TAF failover. There are three options: SESSION,
SELECT, and NONE. Selection of SESSION means that OPS/RAC fails
over the session. A new session will be created automatically for use
on the backup if a user's connection is lost. This type of failover does
not attempt to recover selects after a failover. Choosing SELECT
means that OPS/RAC allows users with open cursors to continue
fetching on them after a failover. Although the performance for this
type of TAF during a failover is good, it has an overhead during
normal select operations. Selection of NONE means that no failover
function is used. This is the default.
The parameter METHOD specifies how fast a failover occurs from the
primary node to the backup node. There are two options: BASIC and
PRECONNECT. Selection of BASIC means that OPS/RAC establishes
connection at failover time. This option requires almost no work on
the backup server until failover time. Selection of PRECONNECT
means that OPS/RAC pre-establishes connections all the time. This is
good for failover performance, but bad for normal operation, since it
requires the backup instance to support all connections from every
supported instance.
Example 12-9 shows a sample tnsnames.ora for OPS/RAC/TAF
configuration with CTF.
Example 12-9 Sample OPS/RAC TAF with CTF tnsnames.ora file

WASOPSTAF.somecorp.com=
(description=
(load_balance=on)
(failover=on)
(address=
(protocol=tcp)
(host=opshp1)
(port=1521)
(address=
(protocol=tcp)
(host=opshp2)
(port=1521)
(connect_data=
(service_name=WASOPSTAF.somecorp.com)
(failover_mode=
(type=session)
(method=preconnect)
(retries=0)
(delay=10))))

Alternatively, Example 12-10 shows a sample tnsnames.ora for the

OPS/RAC/TAF with primary and secondary servers configured.
 Example 12-10 Sample OPS/RAC TAF with primary/secondary
servers tnsnames.ora file

WASOPSTAF.somecorp.com=
(description=
(address=
(protocol=tcp)
(host=opshp1)
(port=1521))
(connect_data=
(service_name=WASOPSTAF.somecorp.com)
(failover_mode=
(backup=opshp2)
(type=session)
(method=preconnect)
(retries=0)
(delay=10))))

WebSphere® works with OPS/RAC/CTF failover configurations.

WebSphere® also works with some of OPS/RAC/TAF failover
configurations, for example TYPE of SESSION, and METHOD of both
BASIC and PRECONNECT.

Configuring WebSphere® servers

Install the Oracle client in the hosts where you plan to install
WebSphere. Install WebSphere® as described in the manual, using
the OCI driver to connect the WASs to the databases created. Since
we use the global net service name, which is independent of
individual nodes, the failover is transparent to WebSphere. For CTF,
WebSphere® receives a few StaleConnectionExceptions during an
OPS/RAC failover, and WebSphere® handles these exceptions
automatically. WebSphere® usually works automatically after an
OPS/RAC/TAF failover.
In summary, although OPS/RAC uses non-IP failover, it still needs
platform-specific cluster software to provide cluster management
and inter-process communication. OPS/RAC failover takes a very
short time. It is almost instantaneous failover, because non-IP
takeover is used and no restarting of the database instance is
needed. WebSphere® establishes connections immediately after a
failover, and clients observe very few failures.