Anyone who’s tuned a high-concurrency OLTP system on RAC knows this pain: your indexes are fine, your SQL is fine, and yet throughput still crawls the moment you scale nodes. Nine times out of ten, the culprit is a right-growing index — and Cache Fusion paying the price for it.
Oracle RAC has always been solid on availability and scalability. But write-heavy workloads hitting sequential indexes have been a persistent sore spot for as long as I’ve been tuning these environments. Every INSERT competing for the same leaf block, every commit waiting on a block transfer from another instance — it adds up fast at scale.
Oracle AI Database 26ai on Exadata finally takes a real swing at this with two features working in tandem: the In-Memory Transaction Table and the Commit Cache. Between the two, Oracle cuts down inter-node chatter in a way that actually shows up in your AWR reports.
The Problem, in Plain Terms
Picture an application inserting new rows into a table with a primary key index — nothing exotic, just a standard sequence-based key. Because new values always land at the tail end of the index, every RAC instance doing inserts ends up fighting over the same leaf blocks.
That fight shows up as:
- TX index contention
- A spike in Cache Fusion block transfers
- Commits taking longer than they should
- Rising
gc buffer busywaits - Throughput that just won’t scale past a certain point
If you pull an AWR report on an affected system, you’ll typically see the usual suspects near the top:
gc buffer busy acquire
gc buffer busy release
enq: TX - index contention
gc current block busyIf TX - index contention is sitting near the top of your wait events, right-growing indexes are probably your issue — I’ve diagnosed this exact pattern more times than I can count on banking and telecom systems.
What Exactly Is a Right-Growing Index?
It’s any index where inserts consistently land at one edge rather than spreading across the structure. Common examples:
- Identity columns
- Sequence-generated primary keys
- Timestamp-based indexes
- Order numbers that only ever go up
So you get something like:
1001
1002
1003
1004
1005Every single insert targets the same, newest block. When several RAC nodes are inserting concurrently, they’re all reaching for that same block at once — and that’s where the Cache Fusion overhead comes from.
Enter the In-Memory Transaction Table
Oracle’s fix here isn’t to eliminate the contention outright (that’s an application design problem), but to make the cost of resolving it far cheaper. Instead of shipping entire transaction blocks between instances every time one needs to know a commit status, Oracle now keeps a lightweight in-memory cache of committed transaction info. An instance that needs to check a transaction’s status just pulls the metadata it actually needs — nothing more.
How It Used to Work
That “entire transaction block transferred” step is the expensive part — and it happened constantly under heavy write load.
How It Works Now
Rather than requesting a full block:
- The instance sends just the Transaction ID (XID)
- The remote instance runs an RDMA lookup
- Commit info comes back
- No block transfer needed
It’s a small architectural change on paper, but it removes a genuinely expensive operation from a very hot code path.
Batching Makes It Even Better
Oracle didn’t stop at trimming individual lookups — it batches them too. Say ten sessions commit at roughly the same time. On older RAC versions, that’s ten separate round trips. On 26ai, all ten XIDs go out in a single batched message instead:
Batch Message
------------------
XID1
XID2
XID3
XID4
...
XID10
------------------One message instead of ten. Under real batch-heavy OLTP load — think end-of-day settlement runs or bulk order processing — that adds up to a meaningful drop in interconnect chatter.
The Commit Cache
The second piece of this puzzle is the Commit Cache. Each RAC instance now keeps its own in-memory record of commit timestamps, and remote instances can query that cache directly via RDMA instead of pulling transaction table blocks to figure out commit status.
No block movement at all — just a fast, low-latency RDMA read.
In practice, this means:
- Commit timestamps stay resident in memory
- Log-related waits drop off
- Cache Fusion traffic goes down
- Batching gets even more efficient
- Full transaction block transfers become largely unnecessary
Oracle’s own numbers put the reduction in Cache Fusion block traffic at up to 60% for batch-heavy workloads — your mileage will vary depending on how skewed your inserts are, but even a fraction of that is a noticeable win on a busy OLTP system.
What This Actually Changes for You
Less TX index contention — fewer instances fighting over the same blocks.
Lower Cache Fusion traffic — fewer block transfers crossing the interconnect.
Faster commits — status comes straight from memory instead of a remote block fetch.
Better use of RDMA — low-latency lookups instead of full transfers.
More efficient batching — one network round trip covers many transactions at once.
Higher overall throughput — less overhead per transaction means more transactions get through.
Old vs New, Side by Side
| Traditional RAC | Oracle AI Database 26ai |
|---|---|
| Multiple transaction block transfers | In-memory transaction lookups |
| Multiple network messages | Single batched message |
| Full transaction block movement | XID-only lookup |
| Higher Cache Fusion traffic | Up to 60% less for batch workloads |
| TX index contention | Significantly reduced |
| Higher commit latency | Faster commit processing |
Where This Matters Most
If you’re running any of the following on RAC, this is worth paying attention to:
- High-volume OLTP systems
- Banking applications
- Payment platforms
- Order management systems
- Retail platforms during peak load
- ERP workloads
- Anything built around sequence-generated primary keys
- Large Oracle RAC databases on Exadata
Basically, if your AWR reports have ever shown TX - index contention near the top, this feature was built with your system in mind.
Availability
These capabilities ship with Oracle AI Database 26ai on Exadata, taking advantage of RDMA and Exadata’s high-speed interconnect to make the transaction lookups as fast as they are.
Final Thoughts
Oracle RAC has been optimizing Cache Fusion for years, but the In-Memory Transaction Table and Commit Cache feel like a genuinely different approach rather than another incremental tweak. Swapping full block transfers for lightweight XID lookups over RDMA, and batching those lookups on top, addresses a bottleneck that’s been baked into RAC’s design since sequence-based keys became the default for primary keys.
For teams running write-heavy Oracle RAC workloads on Exadata — especially anywhere right-growing indexes are unavoidable — this is one of those 26ai features worth testing early. The upside is real, and it doesn’t require rewriting your application to get it.
