Oracle RAC Services: The Right Way to Connect Applications to RAC
One of the most common mistakes in Oracle RAC environments is connecting applications directly to a database instance.
For example:
Application → ORCL1
This configuration works, but it defeats many of the benefits of RAC. If ORCL1 becomes unavailable, the application loses its connection even if another instance is still running.
Oracle recommends connecting applications through Database Services instead.
Services provide an abstraction layer between the application and the database instances. They allow Oracle Clusterware to decide where connections should be established and where they should move in the event of a failure.
In this article, we’ll explore Oracle RAC Services, how they work, and why every production RAC environment should use them.
What is an Oracle Service?
An Oracle Service is a logical name used by applications to connect to the database.
Instead of connecting to a specific instance, the application connects to a service.
Example:
Application
|
|
SALES_APP
|
+-----------+
| RAC DB |
+-----------+
| |
ORCL1 ORCL2
The application doesn’t need to know which instance is handling the session.
Why Use Services?
Services provide several advantages:
- Load balancing
- High availability
- Fast failover
- Workload isolation
- Easier maintenance
- Better scalability
They also make it possible to move application workloads between RAC instances without changing connection strings.
Services vs Instances
Many people confuse these two concepts.
| Instance | Service |
|---|---|
| Physical database instance | Logical application endpoint |
| Runs on one node | Can run on one or more instances |
| Starts the database | Routes client connections |
Think of it this way:
- Instance = Server
- Service = Business Application
Example Architecture
Clients
|
SCAN Listener
|
SALES_SERVICE
|
+------------+------------+
| |
ORCL1 ORCL2
Applications connect to SALES_SERVICE, not directly to ORCL1 or ORCL2.
Creating a Service
Create a service with srvctl:
srvctl add service -d ORCL -s SALES -r ORCL1 -a ORCL2
Where:
-r= Preferred instance-a= Available instance
This means:
Normally:
SALES ↓ ORCL1
If ORCL1 fails:
SALES ↓ ORCL2
The service relocates automatically.
Starting a Service
srvctl start service -d ORCL -s SALES
Check its status:
srvctl status service -d ORCL
Example:
Service SALES is running on instance ORCL1
Viewing Services
SQL query:
SELECT name, network_name FROM dba_services;
Example:
NAME NETWORK_NAME
SYS$USERS SYS$USERS
SALES SALES
Preferred and Available Instances
Suppose a two-node RAC cluster:
Node1 ORCL1 Node2 ORCL2
Configure:
Preferred: ORCL1 Available: ORCL2
Normal operation:
Users ↓ ORCL1
Failure:
Users ↓ ORCL2
The application continues to use the same service name.
Administrator-Managed vs Policy-Managed
Oracle supports two placement models.
Administrator-Managed
You explicitly choose:
- Preferred instance
- Available instance
Example:
SALES ↓ ORCL1
Policy-Managed
Oracle chooses where services run based on server pools and cluster policies.
This model is common in larger RAC environments where automatic workload placement is preferred.
Load Balancing
Oracle RAC supports two types of load balancing.
Client-Side Load Balancing
The client connects to one of the SCAN listeners.
Application ↓ SCAN ↓ Listener1 Listener2 Listener3
Server-Side Load Balancing
The listener evaluates the workload on each instance and directs new sessions to the most suitable instance.
SCAN ↓ Oracle Listener ↓ Least Loaded Instance
Service Relocation
One of the biggest advantages of services is online relocation.
Example:
Before SALES ↓ ORCL1
Move the service:
srvctl relocate service -d ORCL -s SALES -i ORCL1 -t ORCL2
After relocation:
SALES ↓ ORCL2
Existing sessions may continue or reconnect depending on the application configuration.
Viewing Active Services
srvctl status service -d ORCL
Database view:
SELECT name, goal, clb_goal FROM gv$services;
Useful columns include:
- Service name
- Runtime Load Balancing Goal
- Connection Load Balancing Goal
Runtime Load Balancing
Oracle continuously monitors workload.
If one instance becomes overloaded:
Instance1 90% Instance2 35%
New connections are directed toward the less busy instance.
This improves resource utilization across the cluster.
Fast Application Notification (FAN)
When a node fails, Oracle immediately notifies supported clients.
Instead of waiting for TCP timeouts:
Node Failure ↓ FAN Event ↓ Connection Closed ↓ Reconnect
This significantly reduces application recovery time.
Application Continuity
Application Continuity can automatically replay eligible requests after a recoverable failure.
Example:
User ↓ UPDATE Customer ↓ Node Failure ↓ Reconnect ↓ Replay Request
For supported workloads, users may not even notice that a node failed.
Transaction Guard
Transaction Guard helps determine whether the last transaction was committed.
Without it:
Application ↓ Network Failure ↓ Unknown Status
With Transaction Guard:
Application ↓ Ask Database ↓ Committed? ↓ YES / NO
This prevents duplicate transactions caused by uncertainty after failures.
Common Service Problems
Service Offline
Check:
srvctl status service -d ORCL
Start if necessary:
srvctl start service -d ORCL -s SALES
Service Not Registered
Verify listeners:
lsnrctl status
Confirm the service appears in the registered services list.
Application Connecting to an Instance
A connection string like:
ORCL1.wadhahdaouehi.tn
should be replaced with:
sales.wadhahdaouehi.tn
or the SCAN name combined with the service name.
Avoid hardcoding instance names in application connection strings.
Uneven Workload
Verify:
SELECT inst_id,
service_name,
COUNT(*)
FROM gv$session
GROUP BY inst_id, service_name
ORDER BY inst_id;
This query helps identify whether sessions are distributed as expected.
Useful Commands
List services:
srvctl config service -d ORCL
Check status:
srvctl status service -d ORCL
Start:
srvctl start service -d ORCL -s SALES
Stop:
srvctl stop service -d ORCL -s SALES
Relocate:
srvctl relocate service -d ORCL -s SALES -i ORCL1 -t ORCL2
Best Practices
- Never connect applications directly to an instance.
- Always use services with the SCAN name.
- Separate OLTP and reporting workloads into different services.
- Define preferred and available instances appropriately.
- Test service relocation during maintenance windows.
- Use Application Continuity and Transaction Guard where supported by the application and Oracle client.
Production Scenario
A customer experienced repeated outages during monthly operating system patching.
The application connected directly to ORCL1, even though a second RAC instance was available.
Each time Node 1 was rebooted, every user lost connectivity until the node came back online.
The solution was straightforward:
- Create a dedicated application service.
- Configure ORCL1 as the preferred instance.
- Configure ORCL2 as the available instance.
- Update the application to connect using the SCAN name and the service.
At the next maintenance window, the service was relocated to ORCL2 before patching began. Users continued working with only brief reconnects managed by the application, and the downtime was effectively eliminated.
DBA Tip
One question I often ask during RAC health checks is:
“Does your application connect to a service or to an instance?”
If the answer is “ORCL1” or “ORCL2,” there is usually room for improvement.
RAC provides high availability only when applications are designed to use RAC features. Database services, SCAN listeners, and appropriate client drivers allow Oracle Clusterware to redirect workloads during failures and planned maintenance.
Buying RAC gives you the infrastructure. Using database services correctly is what delivers the high availability.
Conclusion
Oracle RAC Services are the foundation of high availability and workload management. They separate applications from individual instances, enabling load balancing, automatic failover, service relocation, and advanced features such as FAN, Application Continuity, and Transaction Guard.
Designing applications around services instead of instances is one of the most important best practices in any production RAC environment.
Google+
Facebook
