Oracle RAC (Real Application Clusters) Configuration and Testing With WebLogic Server Support Pattern
(Doc ID 1148726.1)
Last updated on SEPTEMBER 11, 2020
Applies to:Oracle WebLogic Server - Version 8.1 to 10.3.5
Oracle WebLogic Server - Version 10.3.6 to 10.3.6
Information in this document applies to any platform.
***Checked for relevance on 27-Jul-2016***
Real Application Clusters (RAC) is a quasi High Availability configuration that provides load balancing between nodes in a RAC instance, failover, and scalability of a data base. It provides a way of adding nodes to a database, increasing capacity, and increasing performance. In WebLogic Server 8.1 SP4 and higher, Oracle RAC is supported: see here for details.
What is Oracle RAC?
Oracle RAC is an Oracle database that has two or more instances accessing a shared database via cluster technology. A cluster is a group of machines (or nodes) that work together to perform the same task. To support this architecture, two or more machines that host the database instances are linked by a high-speed interconnect to form the cluster. The interconnect is a physical network used as a means of communication between each node of the cluster. Cluster functionality is provided by the OS or third party software (e.g. Veritas) so you need to insure that the clustering or High Availability subsystem is compatible with RAC.
Oracle RAC Installation
The majority of the failover and load balancing work is done by the JDBC drivers provided by Oracle and represents a black box implementation to WLS. As a result, the primary task for WLS is to insure the JDBC is configured to pass the appropriate parameters to Oracle JDBC drivers. In addition, there is the RAC component that uses the clustering and transaction recovery feature that comprise the RAC implementation on the Data Base (DB).
Most issues seen by users are behavior at failover, although load balancing and recovery are also supported by RAC. Since RAC implements multipool functions, WLS has no control over any latency associated with failover or even recognizing the need to failover. Failover behavior is different depending on the reason to failover. If the Oracle database fails (the oracle node or DB terminates, but the OS is still running) the failover should be fast. However, if there is a hardware/OS failure, failover can take some time due to TCP latencies (same caveats apply to all WLS multipool implementations).
The user expectation is that of a High Availability system, one that seamlessly and immediately fails over. Of course, given the restrictions listed above, that does not always happen.
In addition, if there are transactions started when the Oracle DB fails, the failover behavior will depend on the phase or cycle of the transaction (begin, prepare, or committed). RAC provides a degree of recovery, meaning that prepared transactions can be recovered from the failed Oracle DB. Until transactions are "prepared," they are in-memory and, therefore, not written to disk and cannot be recovered.
RAC is dependent on OS clustering technology to provide the shared disk required for data integrity. This can be provided by a third party such as Veritas for SUN, or from the OS/hardware vendor.
Users need a better understanding of the following:
- Configuration of the JDBC drivers
- Expectation of the services provided
- How to take advantage within WLS
Please note that not all of the following items would need to be done. Some issues can be solved by only following a few of the items.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document
|What is Oracle RAC?|
|Oracle RAC Installation|
|Why does the problem occur?|
|Testing RAC Configuration|
|Need further help?|