Oracle RAC active/active

The Oracle Real Application Cluster (RAC) is a share-everything database cluster with a distributed lock manager.

As a share-everything database, all RAC nodes access and update the same data files. The distributed lock manager controls which node updates the data. It does not matter on which node the transaction is performed. Each node has equal rights to access the data in the shared database.

Each RAC node has a listener process that is responsible for processing the database connection requests from client programs. When the listener receives a request, it could spawn off a new database process to which the client program connects to. If server-side load balancing is enabled, the listener could send the request to the listener on the least busy RAC node.

Oracle has introduced the Grid Infrastructure from Oracle RAC 11g Release 2. With this, Oracle has integrated two of its products – Oracle ASM and the Oracle Clusterware in one software bundle. Oracle Grid Infrastructure provides the necessary functions for volume management, file system, and server pool management to run an Oracle RAC database.

Configuring Sterling Order Management System Software with Oracle RAC

When configuring Sterling™ Order Management System Software with Oracle RAC, you want the RAC nodes to be reasonably balanced so that all RAC nodes, over a period of time, are about the same utilization. During a node failure, you also want the connections from the failed node to automatically reconnect to the surviving RAC node. You can do this using Oracle features on the client-side and server-side.

Client-side load balancing using SCAN

Oracle RAC 11g Release 2 introduces the Single Client Access Name (SCAN) to simplify client access to databases. SCAN allows a single name to be used in the client connection requests that does not change as the cluster expands, or if any of the nodes in the cluster changes over time. This allows the use of simplified connect strings for JDBC. You must define the SCAN in your DNS as a single name that round robins to different IP Addresses of the nodes. These IP addresses must be on the same subnet as the public network for the cluster.

The jdbc url are:

jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=ON)(FAILOVER=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=racscan)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=racdb)))

Oracle RAC 11g Release 2 introduces the Grid Naming Service (GNS), which makes it easier to scale by automating the VIP management for Oracle RAC. Sterling Order Management System Software 9.1 has not been tested with GNS enabled.

For more information on SCAN, please refer Oracle RAC documentation.

All the database nodes will have the following values in the tnsnames.ora file


 RACDB =
  (DESCRIPTION = 
   (ADDRESS = (PROTOCOL = TCP)(HOST = racscan)(PORT = 1521)) 
    (CONNECT_DATA = 
    (SERVER = DEDICATED)
    (SERVICE_NAME = racdb)
   )
    )

RACDB is the net_service_name for client-side load balancing, as illustrated in the following figure:

A diagram depicting load balancing on the client side.

From a Sterling Order Management System Software perspective, you can expect the following to occur after a RAC server instance failure:

Transactions in the application, agent and integration servers that were actively processing throws a SQL error message. The remaining RAC nodes roll back the changes from those transactions.
The Sterling Order Management System Software agent and integration servers continually attempt to reconnect. When it has connected to one of the remaining RAC instances, the failed transactions are reprocessed. You do not have to restart the Sterling Order Management System Software servers during the transition to one of the other active nodes.
If the source of the work request (specifically for the agents and integration servers) came from message queues, the messages remain in the message queue. When the database service is restored, these messages are processed.