OPS and IP Failover

In the event of a node failure in an OPS environment, Oracle SQL*Net or Net8 clients may be configured to reconnect to the surviving server without the use of IP failover.

In an OPS environment, multiple Oracle instances cooperate to provide access to the same shared database. The Oracle clients can access the database using any of the instances. Thus, if one or more instances have failed, clients can continue to access the database by connecting to a surviving instance.

There are many ways to reconnect to a surviving instance so that the reconnection is transparent to the end user:

• Design the application such that if the Oracle client loses the connection to the Oracle instance, it reconnects to an alternate instance. This implies the client is aware that it is operating in a multi-instance (OPS) environment.

However, such a solution is seldom used. Instead, most implementations use middle ware, such as the Tuxedo transaction monitor (TM), to implement the reconnection logic. The Oracle client connects to the TM, which in turn connects to one of the many database instances. The TM hides the failure of a particular database instance from the clients by reconnecting to alternate instances. The advantage of the TM approach is that existing Oracle client applications need not be rewritten to take advantage of the multiple instances in an OPS environment. The disadvantage is the cost of integrating with a TM.

• Design the application (Oracle client) such that when it loses the connection to the database instance, it retries the connection to the same server. Thus, Oracle client applications designed for a non-parallel environment can be moved into an OPS environment without redesign. The infrastructure is then designed to ensure the connection is routed to the surviving server.

High Availability Features of the Oracle SQL*Net

From the Oracle client perspective the model is simple, when the server crashes the client sees a broken connection. The client reconnects to the server, and resubmits the transaction. The Oracle SQL*Net provides features and capabilities to incorporate multiple instances running on different hosts under the same service. Hence, when the client reconnects, it is automatically connected through to the surviving instance. The reconnection is not automatic. The client typically incorporates the code to reconnect broken connections (to the same service as before).

With a node or instance failure, the surviving instance(s) must first recover the failed instances state. During this recovery time clients will see a lack of response from the instance. This recovery has nothing do with the Sun Cluster framework. Recovery is totally dependent on Oracle, the transaction volume, and recovery mechanism for OPS.