Database Reference
In-Depth Information
TAF is relatively easy to configure; however, this feature requires the OCI (Oracle Call Interface) library and
doesn't work with a JDBC thin driver, which is widely used in many Java applications. Another disadvantage is
that TAF mainly works with the session that runs the SELECT query statement. If the session fails in the middle of
executing a DML or DDL or a PL/SQL program such as a stored procedure, a function, or a package, it will receive the
ORA-25408 error, and the database will roll back the transaction. The application needs to reissue the statement after
failover. These disadvantages lead us on to a discussion of another alternative called the Fast Connect Failover (FCF).
Fast Connect Failover (FCF)
Fast Connect Failover (FCF) provides a better way to fail over and recover the database connection transparently
during an instance failure. The database clients are registered with Fast Application Notification (FAN), a RAC HA
framework that publishes Up and Down events for the cluster reconfiguration. The database clients are notified of
these Up and Down events published by FAN and react to the events accordingly. When an instance fails, FCF allows
all database clients that connect to the failed instance to be quickly notified about the failed instance by receiving
the Down event. Then, these database clients will stop and clean up the connections and immediately establish
new connections to the surviving instance. FCF is supported by JDBC and OCI clients, Oracle Universal Connection
Pool(UCP), and Oracle Data Providers for .Net. Oracle FCF is more flexible than TAF.
Connect to the RAC Database with VIPs
In the configuration of a database connection using tnsnames.ora and Java thin client driver, a VIP (instead of the
database hostname (IP)) must be used for the hostname to avoid the TCP timeout issue, as shown in the following
example.
KHDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = kr720n1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = kr720n2-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME =
khdb.dblab.com
)
)
)
)
This is because if the host is not accessible, then the user that connects this host with the hostname has to wait
for the TCP/IP timeout to determine the host connection failure. Moreover, this timeout can range from a few seconds
to a few minutes. In the worst case, therefore, the client may have to wait for a few minutes to determine if the host
is actually down. During these few minutes, the database instance may have already been down and the database
connection may be frozen, but the client does not know about the down event and will not fail over until the TCP/IP
timeout is completed.
The solution to this problem is to connect the database using the VIP in the connection configuration to
eliminate this timeout issue. The VIP is a CRS resource managed by Oracle Clusterware. When the host fails, the CRS
automatically relocates the VIP to a surviving node, which avoids waiting for the TCP/IP timeout. However, after the
relocation, since the listener on the new node listens only to the native VIP on the node, not the VIP relocated from
the other node, this relocated VIP will not have a listener to listen to any database request on this VIP. Any connection
on this VIP will receive the ORA-12541 no listener error. After receiving the error, the client will try the next address
to connect to the database. In the preceding example of KHDB connection string, when node 1 k2r720n1 fails, the
kr720n1-vip fails over to node 2 k2r720n2. Any connection using kr720n1-vip will receive the ORA-12541 no listener
error and TAF will switch the connection to the next entry on the address list to connect to node 2's VIP: kr720n2-vip.
This switch is immediate without waiting for the TCP/IP timeout.
