General Information for Parallel Database Systems

Shared Disk Architecture

The shared disk configuration of Sun Cluster is used by OPS. In this configuration, a single database is shared among multiple instances of OPS, all of which access the database concurrently. Conflicting access to the same data is controlled by means of a distributed lock manager (the Oracle UNIX Distributed Lock Manager (DLM)). If a process or a node crashes, the DLM is reconfigured to recover from such failure.

Shared Nothing Architecture

The shared nothing disk configuration of Sun Cluster is used by Informix-Online XPS. The database server instance(s) on each node has sole access to its own database partition.

A database query from a client is analyzed by the servers for its table partitions and forwarded across the private network to the appropriate servers. The results are merged across the private network and returned to the client.

Shared Memory Issues

Some applications (OPS, for example) sometimes require modification of the /etc/system file so that the minimum amount of shared memory that may be requested is unusually high. For example, if the field shmsys:shminfo_shmmin in the /etc/system file is set to a value greater than 200 bytes, the sm_config(1M) command will not be able to acquire shared memory, as it ends up requesting a smaller number of bytes than the minimum the system can allocate. As a result, the shmget(2) system call made by the sm_config(1M) command fails, thus aborting sm_config(1M).

To work around this problem, edit the /etc/system file and set the value of shmsys:shminfo_shmmin to 200. The value of shmsys:shminfo_shmmax should be greater than 200. Then reboot the machine for the new values to take effect.

If you encounter semsys warnings and core dumps, it could mean that the semaphore values contained in the semsys:seminfo_* fields in the /etc/system file do not match the actual physical limits of the machine.

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.