Translate freshness into per-operation requirements
In a fictional funds portal, the process list may tolerate a few seconds of lag while an instruction confirmation must show the write that just finished. Both are SELECT operations, but their service contracts differ. Before designing routing, record each operation’s freshness requirement, authorized identity, response to lag and failure behavior. True Cache can provide a consistent committed state that does not yet include the primary’s latest change. Temporary absence from the cache does not justify replaying a financial write. Diagnosis should preserve the request reference, establish transaction outcome and use an appropriate read route. These examples are fictional and do not represent institutional procedures.
Verify the connection model in use
With two physical connections, the application explicitly chooses the primary or cache service. The JDBC Thin logical-connection design requires client True Cache support and configuration, plus the read-only mode used to select eligible reads. Finding SELECT in code or a cache in inventory is insufficient. The 26ai OCI pool model, available from RU 23.26.0, has distinct options to request the cache or prefer it with primary fallback; OCI here means Oracle Call Interface. Handover should identify client version, applied properties, actual service and mode for each operation. A test should observe the route used, including connections returned to the pool. Intended configuration is not evidence that every connection received the correct state.
Choose the correct instance and metric
V$TRUE_CACHE shows configuration relationships and status: the primary may show one row per cache, while a cache shows its relationship with its primary. Query V$TRUE_CACHE_STAT on True Cache; no rows on the primary does not mean zero lag. Record metric name, unit, instance, TIME_COMPUTED and DATA_TIME. A recomputed measurement based on inputs whose arrival stopped does not establish current synchronization. Documentation also identifies metrics that are not meaningful in this context, including estimated startup time and apply finish time. Do not turn them into an SLA merely because they appear in the view. An incident report should separate healthy connectivity, apply lag, block-fetch latency and application-perceived latency.
Plan warm-up, fallback and primary load
After startup, early queries may need to fetch blocks not yet resident in the cache. Compare the same load under cold and warm conditions while retaining initial state and measurements. Good warm-cache timings do not establish behavior immediately after recovery. When client configuration permits fallback, cache unavailability can concentrate reads on a primary that still processes writes. Include that combination in capacity testing and define load-admission limits. The plan should identify who decides to degrade informational queries and who can authorize traffic changes. Recovery is not accepted solely because one session reconnects.
Distinguish redirected writes and version conflicts
DML redirection sends the change to the primary and the cache subsequently receives the corresponding update. It does not create an independent writable primary; it adds a path whose cost should be evaluated, especially for write-heavy services. For a JSON document protected by an ETAG, an edit based on an older version can be rejected on the primary when data has changed. The appropriate response is to reread and reconcile the intended change under applicable business rules. Blindly repeating the same request or removing version validation can conceal conflict. The technical manager should include concurrency and ambiguous outcomes in testing, retaining request identifiers and clear retry criteria.
Design exercise: eight evidence-based decisions
The table below is an original tabletop exercise, without an executed True Cache instance. For each row, choose routing or investigation, missing evidence and one condition blocking acceptance. A permits cache use only within agreed tolerance and with a valid measurement. B needs a read including the committed write; preserve the reference and do not replay the write because the cache omits it. C is an ETAG conflict requiring reconciliation. D requires querying statistics on the correct instance. E requires investigating telemetry age before using its value. F requires evaluating primary fallback load. G requires comparing cold startup with a warm cache. H limits the conclusion to a healthy relationship; service criteria remain missing. Submit a matrix with owner, route, observation and decision. A solution using HEALTHY as proof of every property is incomplete.
Tabletop exercise. Fictional values and contracts, not actual telemetry.
ID | Operation/symptom | Known condition
A | Process list | Approved 5 s tolerance; recent 2 s lag sample
B | Request R-718 confirmation | Primary commit confirmed; cache read omits request
C | Document D-22 edit | Another user changed the version; PUT with old ETAG rejected
D | Lag diagnosis | V$TRUE_CACHE_STAT has no rows; queried on primary
E | Lag dashboard | DATA_TIME remains 11:12; TIME_COMPUTED advances to 11:20
F | Cache failure | Client permits fallback; primary already runs the closing batch
G | Cache restart | Slow early reads; no controlled cold/warm comparison
H | Delivery gate | V$TRUE_CACHE says HEALTHY; no application measurements
Deliverable: one row per case with route/investigation, owner, evidence and blocking criterion.HEALTHY does not establish that confirmation R-718 is already visible in the cache.
Common pitfalls
Treating SELECT as tolerance for lag; confusing overall status with an SLA; using metrics from the wrong instance; replaying writes after stale reads.
Related topics: Vector search and model migration · Visibility and transaction boundaries · True Cache, reservations, and audit evidence
Cache use depends on the operation contract and current evidence of routing and service behavior.
Reference: Overview of Oracle True Cache · 1Z0-183 public objectives inspected 2026-09-30; revision date not published