Oracle True Cache Explained: Architecture, Deployment, Monitoring, and Production Decisions

What Oracle True Cache Actually Is

Oracle defines True Cache as an in-memory, consistent, automatically managed SQL and key-value cache for Oracle AI Database. It is a read-only Oracle database instance that caches the data blocks an application actually reads. It is mostly diskless, serves normal SQL and supported key-value access, and remains synchronized with a primary database by applying physical redo. When a query needs a block that is not present locally, True Cache fetches that block from the primary and adds it to its cache.

This design combines two independent data paths:

• Redo transport and apply keep blocks already held by True Cache current as changes occur on the primary.
• On-demand block fetch retrieves a missing block when a query first needs it.

That distinction explains most of the operational behavior. A warm cache can answer reads locally and remove work from the primary. A cold cache, a poorly sized cache, or a workload with a very large and constantly changing working set generates block-fetch traffic back to the primary. True Cache is therefore not a magic latency layer; its value depends on workload locality, network latency, redo volume, SGA capacity, and deliberate application routing.

The Consistency Model: The Detail That Matters Most

Oracle states that a query on True Cache returns committed and internally consistent data. That does not mean the result is guaranteed to reflect the latest commit on the primary at the instant the query begins. The visible point in time depends on how far redo apply has progressed.

For a senior DBA, the practical rule is simple: consistent is not the same as current. If a user updates an order on the primary and immediately reads it through True Cache, the query could see the state as of the cache’s applied redo rather than the just-committed value. Applications that need read-your-write behavior should keep that flow on the primary, introduce an appropriate routing rule, or tolerate and measure the lag.

Why IT Managers and Architects Should Care

That can translate into faster customer-facing searches, reporting, product catalogs, reservation lookups, JSON access, and other read-heavy services. It may also reduce the operational burden of keeping a separate cache synchronized with Oracle data because Oracle manages cached blocks and refreshes them through redo.

However, this is an architecture investment—not a switch to turn on blindly. Management approval should depend on measurable results: primary workload reduction, end-user latency improvement, acceptable data freshness, tested failure behavior, infrastructure cost, and confirmed licensing. A proof of concept should report all six, not only the fastest query.

True Cache, or Redis?

Choose True Cache when

• The workload is read-heavy and uses Oracle SQL, indexes, joins, JSON, or vector queries that would be expensive to remodel into application cache objects.
• You want demand-driven caching instead of provisioning and maintaining a complete physical copy of the database.
• The application can route writes and freshness-sensitive reads to the primary while directing scalable reads to a True Cache service.
• The active working set fits reasonably in memory, optionally extended by supported high-performance flash.

Choose Redis or another application cache when

The application needs explicitly managed objects, extremely simple access patterns, custom expiry semantics, counters, streams, or cache behavior independent of Oracle SQL. True Cache removes the burden of invalidating duplicated database data, but it does not reproduce every Redis data structure or every application-managed caching pattern. Oracle also offers a Redis wire-protocol integration path; validate command coverage and application behavior before assuming drop-in equivalence.

These choices are not mutually exclusive. A platform can use Active Data Guard for DR, True Cache for read scaling, and an application cache for session or ephemeral data—but each layer must have a distinct purpose.

Deployment Prerequisites and Design Decisions

Before running DBCA, settle the architecture. Identify the application services, the read-only workload, the maximum acceptable lag, the working-set estimate, network paths, and failure routing. Oracle’s Maximum Availability Architecture guidance recommends two identically configured True Cache instances for a dataset when availability matters.

Core prerequisites include:

• The primary database must run in ARCHIVELOG mode.
• Oracle AI Database software must be installed on the True Cache nodes at supported versions.
• The primary and True Cache use the same DB_NAME, while every database has a unique DB_UNIQUE_NAME.
• Listener, naming, firewall, and bidirectional connectivity must support redo transport, control traffic, and the True Cache block-service connections.
• The password file or supported authentication wallet must be available on the True Cache host.
• If the primary uses TDE, copy/configure the required wallet. Oracle notes that the root container master key is needed to decrypt redo.
• In 26ai, a non-CDB primary is not supported. PDB state on True Cache follows the primary; PDBs are not administered directly on the cache.

Size SGA_TARGET around the useful working set, not the entire database. Configure DB_FILES for the primary’s file count and growth. Choose DB_CREATE_FILE_DEST for the small amount of persistent database infrastructure True Cache still uses. If flash extension is planned, test its latency and endurance under the actual miss pattern.

Creating True Cache with DBCA

Oracle documents DBCA as the simplest configuration method because it coordinates the configuration on both sides. First, on the primary, create the configuration BLOB that packages the password file and, when applicable, the TDE wallet:

$ORACLE_HOME/bin/dbca -configureDatabase \
  -prepareTrueCacheConfigFile \
  -sourceDB PRIMDB \
  -trueCacheBlobLocation /secure/truecache-blob \
  -silent

Transfer the BLOB using your approved secure method. Then create True Cache on the cache node. The following template shows the key parameters; replace every sample value with your validated environment values:

$ORACLE_HOME/bin/dbca -createTrueCache \
  -gdbName PRIMTC1 \
  -sid PRIMTC1 \
  -sourceDBConnectionString primary-scan.example.com:1521/PRIMARY_SERVICE \
  -trueCacheBlobFromSourceDB /secure/truecache-blob/blob.tar.gz \
  -sgaTargetInMB 32768 \
  -pgaAggregateTargetInMB 4096 \
  -tdeWalletLoginType AUTO_LOGIN \
  -listeners LISTENER \
  -silent

For an Oracle RAC primary, Oracle requires the source connection string to use SCAN:port/service_name. Treat the memory numbers above as syntax examples, not sizing recommendations. Keep the final command in the build record, but never publish passwords or production wallet paths.

For a manual build, the defining initialization parameter is:

TRUE_CACHE=TRUE
DB_NAME=PRIMDB
DB_UNIQUE_NAME=PRIMTC1
SGA_TARGET=...
DB_FILES=...
FAL_SERVER=...
FAL_CLIENT=...
REMOTE_LISTENER=...
DB_CREATE_FILE_DEST=...

After the instance is mounted with the correct connectivity and security material, the documented manual workflow uses:

CREATE TRUE CACHE;

Oracle creates the control files, standby redo logs, temporary files, and internal SPFILE needed by the cache. Avoid pre-populating LOG_ARCHIVE_CONFIG or LOG_ARCHIVE_DEST_n before the documented configuration step; DBCA and True Cache configuration manage those settings. An old LOG_ARCHIVE_DEST setting is incompatible with the numbered destination parameters and should be addressed during prechecks.

Service Routing and Application Integration

The safest initial pattern is explicit: one connection or pool for the primary and another for the True Cache read service. It works across languages and makes routing decisions visible. Direct writes, read-after-write flows, and primary-current reads to the primary; repeatable read-heavy traffic to True Cache.

Oracle AI Database 26ai adds simpler application models. The 26ai JDBC Thin driver can expose one logical connection that routes according to connection read-only state, while OCI session-pool integration begins with 26ai RU 23.26.0. Global Data Services can also use the TRUE_CACHE role, application read-only hints, load balancing, and region-aware failover. Treat driver and RU levels as deployment dependencies, not footnotes.

Create and start corresponding application services on the primary and True Cache. If multiple True Caches serve the same service, listener or GDS-based load balancing can distribute sessions. During a planned cache shutdown, stop its service first so new sessions stop arriving and existing work drains cleanly.

Warm-Up, Memory, and Cache Efficiency

A freshly created True Cache starts empty, and a restarted cache may need to restore its useful working set. The first executions can incur block-fetch latency, so enable the application service only after critical queries have warmed the cache. Oracle’s prewarm mechanism can remember blocks from the prior warmed state and fetch them during startup; monitor prewarm progress rather than assuming recovery completion means the cache is ready for full traffic.

For critical small objects, configure a KEEP buffer pool with DB_KEEP_CACHE_SIZE and use DBMS_CACHEUTIL.TRUE_CACHE_KEEP on True Cache. A True Cache-specific KEEP choice overrides the primary object’s KEEP setting. Use this selectively: pinning too much reduces capacity available for the rest of the working set.

A low hit ratio is a symptom, not a complete diagnosis. Correlate it with block-fetch latency, query mix, buffer-cache churn, redo rate, and network round trips. Partitioning separate True Caches by workload or service can improve locality and reduce demand fetches from the primary.

A Practical Monitoring Runbook

1. Confirm the role and open mode

SELECT name, db_unique_name, database_role, open_mode
FROM   v$database;

The expected state is DATABASE_ROLE='TRUE CACHE' and OPEN_MODE='READ ONLY WITH APPLY'. Re-query CURRENT_SCN from V$DATABASE; it should continue advancing.

2. Check the primary/cache relationship

SELECT my_dg_id, remote_dg_id, dest_id,
       true_cache_name, primary_name, status
FROM   v$true_cache;

Run this on both sides. A healthy result validates the relationship, but it does not prove the workload is meeting its latency or freshness target.

3. Measure lag, hit ratio, and fetch cost

SELECT name, value, unit, time_computed
FROM   v$true_cache_stat
ORDER  BY name;

Focus on transport lag, apply lag, True Cache hit ratio, RAM and flash hit ratios, prewarm progress, and single-block, multiblock, and list-of-blocks fetch latency. Oracle notes that apply finish time and estimated startup time are not meaningful for True Cache. This view returns rows on True Cache, not on the primary.

4. Inspect the process paths

SELECT pid, name, dgid, client_pid, role
FROM   v$dataguard_process
WHERE  role LIKE 'True Cache%'
ORDER  BY role;

The process model is highly useful during troubleshooting:

• FCH on True Cache sends missing-block requests.
• RCVR on the primary receives those requests.
• DSNDR on the primary sends the requested blocks.
• DTS on True Cache receives the blocks.

These run alongside familiar Data Guard components such as RFS, FAL, MRP, and real-time apply. If redo apply is healthy but cache misses hang, investigate the FCH/RCVR and DSNDR/DTS paths rather than focusing only on RFS and MRP.

5. Read messages and wait events

SELECT timestamp, dest_id, facility, severity,
       error_code, message
FROM   v$dataguard_status
WHERE  facility = 'True Cache'
    OR error_code != 0
ORDER  BY timestamp;

Correlate the view with both alert logs and, where permitted, operating-system TCP connections for the reported PIDs. Also baseline AWR, application response time, primary DB time, redo bandwidth, and the True Cache-specific statistics in V$SYSSTAT. Enterprise Manager exposes a True Caches dashboard and Performance Hub support on documented EM 24ai Release Updates.

Failure Behavior and High Availability

A single True Cache is a read-scaling component and can become an application dependency. Deploy two equivalent caches when the service requires availability, put them behind supported service routing, and test the loss of one cache while the other is cold, warm, and under load. A failover that doubles sessions on an undersized peer is not a successful HA design.

Decide explicitly what happens if every True Cache is unavailable:

• Fail read traffic back to the primary and accept the capacity impact.
• Fail to another regional True Cache through GDS where the application permits additional latency.
• Reject or degrade noncritical read features to protect the primary.

Test redo transport interruption separately from block-fetch interruption. The former increases freshness lag; the latter mainly hurts misses. The service may still appear available in both cases, which is why functional queries and lag/fetch telemetry belong in health checks.

DML Redirection: Useful, but Not the Default Answer

True Cache can redirect DML to the primary. The change commits there, generates redo, and later updates the cached blocks through apply. Oracle does not recommend this pattern for update-intensive applications because redirection adds work and does not remove the underlying freshness considerations.

Use it for carefully tested convenience cases, not as a reason to ignore workload routing. Explicit primary connections remain easier to reason about for transaction-heavy paths, error handling, and read-after-write guarantees.

Common Design Mistakes

• Treating True Cache as DR: it is not a complete physical standby or a role-transition replacement.
• Ignoring apply lag: query consistency does not guarantee primary-current data.
• Routing every SELECT: some reads are transactionally coupled to recent writes and belong on the primary.
• Skipping warm-up: enabling full traffic against a cold cache can create a burst of primary block fetches.
• Oversizing the promise, undersizing the SGA: a churning cache may move rather than solve the bottleneck.
• Monitoring only hit ratio: lag and miss latency directly affect correctness expectations and response time.
• Assuming Redis equivalence: validate protocol and command behavior for the application.
• Forgetting licensing: Oracle licenses True Cache according to the database edition used for the primary and cache. Verify the current Licensing Information manual and your agreements.

Production Readiness Checklist

• Classify SQL into cache-safe, primary-current, and write workloads.
• Document maximum transport lag, apply lag, and application response-time targets.
• Measure the working set and model cold-start fetch demand.
• Validate database, RU, JDBC/OCI, Enterprise Manager, and GDS compatibility.
• Verify ARCHIVELOG, SRLs, password/wallet handling, TDE keys, listeners, ports, DNS, and bidirectional connectivity.
• Build two caches where service availability requires it.
• Warm critical queries and verify prewarm progress before opening the service.
• Baseline primary DB time and network/redo load before and after traffic migration.
• Alert on apply lag, transport lag, fetch latency, hit ratio, service state, and error messages.
• Test cache failure, redo interruption, block-service interruption, primary restart, cache restart, and traffic fallback.
• Record DBCA cleanup and DROP TRUE CACHE procedures. Confirm they target only the intended cache.
• Complete a licensing and supportability review before production approval.

Frequently Asked Questions

Is True Cache just an Active Data Guard standby without data files?

No. It reuses physical redo transport and apply concepts, but it is demand-populated and includes a separate block-request service. Active Data Guard maintains a complete physical standby and provides broader standby/DR capabilities.

Are True Cache results strongly consistent?

Each query sees committed, internally consistent data as of the redo applied by True Cache. If the application requires the newest primary commit or read-your-write behavior, route that operation appropriately and enforce a lag policy.

Does it require application changes?

Usually some connection or service-routing design is required. Two explicit pools are broadly applicable. Newer JDBC Thin and OCI session-pool options can reduce application changes when the exact 26ai and client requirements are met.

Can one True Cache serve multiple PDBs?

It follows the primary database’s multitenant structure, but PDBs are not directly administered on True Cache and their state follows the primary. Validate service design per PDB and the current documented restrictions.

Final DBA Perspective

True Cache is most compelling when the application already speaks Oracle SQL, the workload repeatedly reads a manageable working set, and the organization wants read scaling without building a separate invalidation framework. Its database-native security and redo-based maintenance reduce a class of application-cache complexity.

The trade-off is operational precision. DBAs must own the freshness contract, block-fetch path, cache warm-up, service routing, and failure capacity. A successful proof of concept should demonstrate more than faster queries: it should show reduced primary load, stable hit ratios, acceptable lag, controlled cold-start behavior, and predictable failover under production-like concurrency.

Oracle References

• Overview of Oracle True Cache
• Overview of True Cache Configuration
• Configuring True Cache Using DBCA
• Monitoring True Cache
• Enabling DML Redirection
• Licensing True Cache
• Inside Oracle True Cache for DBAs: Architecture, Processes and Monitoring