Introduction

In modern high-availability database environments, performance is not just about hardware — it’s about how intelligently requests are routed inside the cluster.

Oracle RAC 19c provides several advanced service routing mechanisms, and one of the most powerful (yet often overlooked) is the Colocation Tag.

The Colocation Tag Oracle RAC 19c feature helps ensure that related database sessions are routed to the same instance, improving cache locality, reducing inter-instance communication, and delivering faster response times.

In this blog, we’ll break down:

• What a Colocation Tag is
• Why it matters in RAC
• How it works internally
• When you should use it
• Real-world benefits for performance tuning

Let’s dive in 👇

---

What is a Colocation Tag in Oracle RAC?

A colocation tag is a service-level routing attribute that ensures sessions with the same tag value are routed to the same database instance whenever possible.

In simple words:

👉 It groups related client sessions and keeps them on the same RAC node.

This is especially useful when:

• Sessions share data
• Sessions belong to the same application module
• Sessions participate in the same transaction group

---

How Client Routing Works in RAC

Before understanding colocation tags, you need to understand how RAC routing works by default.

Normally, Oracle RAC uses:

• SCAN listeners
• Server-side load balancing
• Runtime load balancing advisory (RLB)

These distribute connections across instances to balance load.

But this has a side effect ❗

👉 Related sessions may end up on different nodes
👉 Which causes global cache transfers (block shipping)
👉 And increases interconnect traffic

---

The Problem Without Colocation

Let’s say your application:

• Reads and updates the same set of rows
• Uses multiple sessions for a single workflow

If those sessions go to different nodes:

• Blocks must travel across nodes
• Cache fusion kicks in frequently
• Latency increases

This leads to:

❌ Increased global cache waits
❌ Higher gc cr request / gc buffer busy waits
❌ More CPU and interconnect overhead

---

How Colocation Tag Solves This

With Colocation Tag Oracle RAC 19c, Oracle ensures:

👉 Sessions with the same tag try to connect to the same instance

Result:

✔ Better cache locality
✔ Reduced block pinging
✔ Lower interconnect traffic
✔ Faster transaction processing

---

Architecture Flow with Colocation Tag

Here is how the routing works:

1. Client sends connection request with colocation tag
2. SCAN listener receives request
3. Oracle checks:
   • Existing sessions with same tag
   • Instance hosting them
4. Routes the new session to the same instance

---

Example Scenario

Imagine a banking system:

• Application module: Loan Processing
• Multiple sessions update same customer loan records

Without colocation:

• Sessions land on Node1, Node2, Node3 randomly

With colocation tag:

• All Loan Processing sessions go to Node2

👉 Result: Less block transfer, faster processing

---

Configuring Colocation Tag in Oracle RAC 19c

Colocation tag is defined at the service level.

Example:

srvctl add service -db mydb -service SALES_SVC \
  -preferred node1,node2 \
  -clbgoal SHORT \
  -rlbgoal SERVICE_TIME \
  -colocation TRUE

Applications then pass a tag using:

• OCI
• JDBC
• UCP
• ODP.NET

---

How Applications Use Colocation Tag

Applications can set tags like:

((OracleConnection)conn).setClientInfo("OCSID.TAG", "ORDER_MODULE");

or through connection pools.

All sessions using "ORDER_MODULE" tag will be routed together.

---

Performance Benefits

Using Colocation Tag Oracle RAC 19c can deliver:

🔹 1. Improved Cache Locality

Data blocks remain in the same instance buffer cache.

🔹 2. Reduced Global Cache Traffic

Less need for block transfer across nodes.

🔹 3. Faster Transaction Processing

Transactions avoid inter-instance synchronization delays.

🔹 4. Lower Interconnect Load

Less network overhead between nodes.

🔹 5. Better Scalability

Applications scale more efficiently across RAC nodes.

---

When Should You Use Colocation Tags?

You should use colocation tags when your application:

✔ Uses multi-session workflows
✔ Has session affinity requirements
✔ Performs frequent updates on same data sets
✔ Uses XA or distributed transactions
✔ Needs consistent read/write locality

---

When NOT to Use It

Avoid using colocation tags when:

❌ Workload is completely random
❌ No data sharing between sessions
❌ Strict load balancing is more important than locality

Because forcing sessions to same instance may cause imbalance.

---

Real World DBA Use Case

A large telecom billing system experienced:

• High gc buffer busy waits
• Slow billing cycle processing

After implementing colocation tag per billing cycle group:

✔ 40% reduction in global cache waits
✔ 30% faster batch processing
✔ Lower interconnect utilization

---

Colocation Tag vs Affinity vs Services

Feature	Purpose
Services	Define workload distribution
Instance Affinity	Directs services to instances
Colocation Tag	Groups sessions to same instance

👉 Colocation tag works at session level

---

Integration with QoS Management

In advanced setups:

• QoS can manage services
• Colocation ensures session locality within those services

This creates a fully optimized RAC workload routing model

---

Key Takeaways

✔ Colocation Tag ensures related sessions stay on same instance
✔ It improves cache locality and reduces RAC overhead
✔ It is configured at the service level
✔ It significantly improves performance for OLTP workloads
✔ It is ideal for applications with shared data access patterns

---

Final Thoughts

Oracle RAC is powerful — but to get maximum performance, you must go beyond default load balancing.

The Colocation Tag Oracle RAC 19c feature is a smart optimization tool that allows DBAs and architects to control session placement intelligently.

When used correctly, it can dramatically reduce cluster overhead and boost application performance.