True Cache is one of those Oracle 23ai features that doesn’t get enough attention compared to AI Vector Search. It’s less glamorous — there’s no “AI” in the name — but for organizations running high-traffic Oracle applications with read-heavy workloads, it addresses a very real architectural problem that previously required significant application changes or expensive infrastructure. This post explains how True Cache works, where it fits architecturally, and what you need to know before deploying it.

The Problem True Cache Solves

Classic Oracle read scaling approaches all have significant trade-offs:

Active Data Guard read-only standby: Full database copy, full storage cost, replication lag means reads might be slightly stale, switching between primary and standby requires either application logic or connection pool configuration.

Oracle Database In-Memory: Keeps columnar copies of table data in SGA memory. Excellent for analytics, doesn’t help with point lookups, memory lives inside the primary database — you’re still hitting the primary for every query.

Application-level caching (Redis, Memcached): Works well but requires application changes to manage cache invalidation, cache warming, and consistency. Cached data can be stale. Cache misses hit the database. Cache-aside pattern adds complexity.

True Cache sits in a different architectural position: it’s a read-only Oracle instance that serves SQL queries directly from memory, with automatic consistency maintained by the primary database. No application changes. No cache invalidation logic. No stale data concerns beyond what the replication lag introduces.

Architecture: How True Cache Differs from Everything Else

True Cache is a separate Oracle instance — not a standby database in the traditional sense. It doesn’t have its own datafiles. It has memory. When a query hits True Cache, it’s answered from True Cache’s buffer cache (or SGA). If True Cache doesn’t have the data in memory, it fetches it from the primary database.

The consistency model: True Cache uses a “session-consistent” model. Within a session, you see a consistent view of data. Changes committed on the primary are propagated to True Cache through a dedicated synchronization mechanism — not redo apply like Data Guard, but a more targeted invalidation/refresh mechanism.

sql

-- True Cache is configured at the primary database level
-- Add to primary's init.ora or spfile:
TRUE_CACHE_MAX_SIZE = 4G  -- Memory for True Cache instances
TRUE_CACHE_ENABLED = TRUE
-- Create a True Cache instance (separate Oracle home, same software version)
-- In True Cache instance init.ora:
TRUE_CACHE = TRUE
PRIMARY_DB_UNIQUE_NAME = primary_db
PRIMARY_HOST = primary_host

What Gets Cached and What Doesn’t

True Cache is not a full database replica. It caches data on demand — blocks accessed through True Cache are loaded into True Cache’s buffer cache and served from memory on subsequent accesses.

Queries that benefit most:

• High-frequency point lookups by primary key or unique index
• Reference data reads (lookup tables, configuration data, catalog data)
• Session state reads in web application backends
• Any read workload where the same data is accessed repeatedly

Queries that don’t benefit:

• Full table scans (True Cache doesn’t have all data pre-loaded)
• Analytics queries spanning large portions of the database
• DML (True Cache is read-only — writes go to primary)
• Queries requiring very fresh data where even milliseconds of lag are unacceptable

Connection Routing — The Application Transparency Story

This is where True Cache’s value proposition is strongest. Application transparency is achieved through JDBC Thin driver routing — your application connects using a standard connection string, and the driver routes read-only transactions to True Cache automatically.

java

// Application connection string — same as before, driver handles routing
Properties props = new Properties();
props.setProperty("user", "app_user");
props.setProperty("password", "password");
props.setProperty("oracle.jdbc.useTrueCacheForReadOnlyConnections", "true");
Connection conn = DriverManager.getConnection(
    "jdbc:oracle:thin:@//primary_host:1521/service_name", props);
// Read-only transaction automatically routed to True Cache
conn.setReadOnly(true);
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM products WHERE product_id = 101");
// This query hits True Cache, not primary
// Write transaction goes to primary
conn.setReadOnly(false);
stmt.executeUpdate("UPDATE inventory SET quantity = 99 WHERE product_id = 101");
// This goes to primary

The JDBC driver detects setReadOnly(true) and routes to True Cache. No other application code change needed. For applications that already properly annotate read-only transactions (as they should for good practice), the migration to True Cache is a JDBC property change and connection string update.

Sizing True Cache

True Cache’s effectiveness is entirely dependent on your working set fitting in its memory. If your application’s hot data — the data accessed in 80% of queries — fits in True Cache’s buffer cache, you’ll see dramatic primary database offload. If your working set is larger than True Cache’s memory, you’ll see high True Cache miss rates and the offload benefit is minimal.

sql

-- On primary: estimate your working set size
-- Check buffer cache contents and hit ratio
SELECT name, value FROM v$sysstat
WHERE name IN ('db block gets', 'consistent gets', 'physical reads');
-- Check which segments are hot (most buffer cache activity)
SELECT owner, object_name, object_type,
       logical_reads_delta, physical_reads_delta
FROM v$segment_statistics
WHERE statistic_name = 'logical reads'
ORDER BY logical_reads_delta DESC
FETCH FIRST 20 ROWS ONLY;

Size True Cache’s memory to cover your hot segments with headroom. Start with twice the size of your top-20 hot segments — this gives you room for the working set to expand and for Oracle’s buffer cache management algorithms to work effectively.

Current Limitations to Know

True Cache is a first-generation feature in 23ai. Before deploying in production, be aware:

• Requires Oracle Database 23ai on both primary and True Cache instances
• JDBC Thin driver 23ai required for automatic routing
• Not all SQL features are supported in True Cache (check Oracle documentation for the current exclusion list)
• True Cache instances don’t participate in Data Guard configurations yet — DR for True Cache requires separate planning
• Monitoring and diagnostics tooling is still maturing compared to well-established features

Deploy in development and staging first. Measure the actual offload ratio before committing to a production architecture based on True Cache.