I mentioned True Cache in a couple of blog posts ago, and here I'm writing more details about it. In fact, a short while ago, we installed and configured it in our lab. We did some tests and I saw that it can do what is supposed to do, what it promised to do. Once again, Oracle used its own technological advantage by using a part of its proven technologies in different context to offer a solution for something outside of its usual area, Apps Tier-like caching. So, we see True Cache is available among Oracle Solutions.
True cache is a actually a database instance, a synchronized (Asynchronous Redo Apply) read-optimized database instance. It uses redo stream replication, allowing read workloads to be offloaded without requiring application redesign. It sits near the primary database (logically) and leverages Oracle's redo transport technologies (like the Dataguard) for data replication, for getting the changes from primary. The cache data is put in memory of True Cache and served from there. It is database-level caching architecture that maintains synchronized data using redo apply while serving high-volume read operations independently from the primary system.What True Cache does is to, increase total system throughput, stabilize latency, reduce primary load and enable horizontal read scaling. It is not a replacement for disaster recovery, or it is not something that will help in write-heavy workloads. It is database-native read scaling architecture designed for modern hybrid workloads.
It doesn't store any data in the disk, in the datafiles.( There is no persistent user datafiles in True Cache) It stores all the cached data in its memory.
When it is first started, the cache is empty. Once the apps or sessions that are directed to True Cache encounter cache/block misses, True cache starts to be filled. (Missing blocks are fetched directly from the primary DB )
Only the hot data ( data that is queried by the sessions that are connected to True Cache, maintained by modified LRU and touches counts) is put in the True Cache. So, Oracle's redo transport services runs all the time from primary to the cache, but only the data that is hot, that is in the memory of true cache is fed from transported changes. If the data that is needed by query of a session that is connected to True Cache is not in the cache, then it is received from primary and served to the query of the session that is requesting it. Subsequent queries that needs the same data will be served directly from the True Cache itself, without a need to go and get the data from primary. As you may guess, after that point, any redo that changes that data, will be applied into the True Cache version of that data. So redo replication is always and already there, but application of the redo is done to the data that is already present in the True Cache.
As you may already understand, True Cache is filled automatically once you query it. The queries shape the cache. So, a true cache that is serving the sales app / sales app sessions automatically becomes a cache dedicated to sales, likewise a true cache that is is serving the finance app/finance sessions all the time, automatically becomes the cache of finance data.
Okay we draw the big picture. Details are there if you need it but I think we are good to go with a test; with a validation.
Well, to validate Oracle AI Database 26ai True Cache behavior from an application perspective, we did some tests with a simple Java application and Oracle JDBC Thin Driver. Our goal was to simulate a real application connection and measure query performance directly at the application layer.
The application connected to the True Cache instance using standard JDBC connectivity:
jdbc:oracle:thin:@//192.168.1.113:1522/FREE_TC
The session was configured as read-only, consistent with the True Cache architecture where read workloads are served by the cache instance while the primary database remains responsible for transactional operations. Connection validation confirmed that queries were executed against a database with the role TRUE CACHE.
Okay.. first performance testing was performed by executing the same SQL query twice within a single session:
I know what the skeptics might be thinking: Is a SELECT COUNT(*) really enough to benchmark a new caching layer?' Well, let's be clear.. This wasn't intended to be a definitive enterprise benchmark. Instead, consider this a structural validation or a smoke test.
Our goal was to observe the fundamental transition from a cold start to a warm state. While a COUNT(*) might primarily hit index blocks or metadata depending on the optimizer's path, it perfectly demonstrates how the instance learns the workload, fetches the necessary blocks from the primary, and eliminates latency on the subsequent pass. It’s about proving how it works before we start measuring the flow rate of a complex production system.
SELECT COUNT(*) FROM SYS.TC_TEST;
As seen above; the first execution acted as a warmup run, allowing data to be populated into the cache. The second execution represented a cache-hit run, where results were expected to be served directly from True Cache memory structures. Execution time was measured within the application using high-resolution timers.
Well.. The performance metrics speak for themselves, but as with any enterprise-grade technology, these results are naturally contingent on a variety of environmental factors (correct SGA sizing, network speed and so on) and specific use cases.
Next, we tested the true cache performance with a join query; (5000 records in each table)
Again performance
testing was performed by executing the same SQL query twice within a single
session:
SELECT c.city, p.category, COUNT(*) order_count,
SUM(oi.quantity * oi.unit_price) total_revenue
FROM SYS.CUSTOMERS c
JOIN SYS.ORDERS o ON o.customer_id = c.id
JOIN SYS.ORDER_ITEMS oi ON oi.order_id = o.id
JOIN SYS.PRODUCTS p ON p.id = oi.product_id
GROUP BY c.city, p.category
ORDER BY total_revenue DESC;
SUM(oi.quantity * oi.unit_price) total_revenue
FROM SYS.CUSTOMERS c
JOIN SYS.ORDERS o ON o.customer_id = c.id
JOIN SYS.ORDER_ITEMS oi ON oi.order_id = o.id
JOIN SYS.PRODUCTS p ON p.id = oi.product_id
GROUP BY c.city, p.category
ORDER BY total_revenue DESC;
Okay good. More realistic :) Primary - Buffer Cache warmup is a little faster here, which may be expected. But once the True Cache is warmed up / once that data is fetched from primary, this time True Cache query performs a little faster :) Again, these results are naturally contingent on a variety of environmental factors (correct SGA sizing, network speed and so on) and specific use cases.
What’s clear, however, is that Oracle True Cache introduces a fascinating new layer to the stack. When configured correctly and aligned with the right workload, it offers a tangible path to offloading the Primary and accelerating data delivery.
We have only scratched the surface here, and the real-world potential of this true caching layer is something I look forward to exploring further. Stay tuned for more deep dives into specific configuration strategies and performance tuning in upcoming blog posts..!
I almost forgot, one piece of information regarding the license: Oracle True Cache is a database feature included in your Oracle AI Database 26ai Enterprise Edition license at no additional cost.