True Cache

How True Cache works

True Cache is a fully functional, read-only replica of the primary database that is mostly diskless.

Modern applications often require a high number of connections and fast, low-latency access to the data. A popular approach is to place caches in front of the database because applications typically perform many more reads than updates, and they can read from the cache without affecting database performance. For example, an airline reservation system reads data frequently as people shop for flights. It's okay if the data isn't the most current compared to what's in the database because the application only needs to access the most current data when someone reserves a flight.

Unlike conventional caches, True Cache automatically keeps the most frequently accessed data in the cache, and it keeps the cache consistent with the primary database, other objects in the same cache, and other caches. It caches all Oracle Database objects and data types, including JSON.

Because True Cache implements Oracle Database security policies, you can control access to the cache. This enables you to cache sensitive data, such as private personal information, that you might not ordinarily cache.

An application decides whether to query data from True Cache or the primary database. For example, the application can maintain two connections: a read-only connection to True Cache and a read/write connection to the database. Alternatively, a Java application can use one connection and dynamically switch between True Cache and the database by setting the read-only attribute.

With True Cache, data is always consistent within a single query. This is even more important when there are joins across multiple rows; doing this at the application level can lead to incorrect results.

How True Cache works diagram description

1. 1. An application directs queries to True Cache either manually or semiautomatically via the Oracle JDBC driver.
2. 2. A True Cache instance satisfies queries by using data that it caches for the database application services that it handles.
3. 3. When a cache miss occurs, a True Cache instance fetches blocks from the primary database instance.
4. 4. When a True Cache instance is first initialized, SQL queries are fired to warm up the cache, resulting in the fetching of surrounding blocks in large chunks.
After a block is cached, it's automatically updated through redo apply from a primary database, usually with a subsecond lag.This is similar to how a real-time redo apply happens in an Oracle Data Guard configuration. The primary database redo blocks are continuously sent to the True Cache standby redo log files by the Log Writer (LGWR) process on the primary database instance in ASYNC mode.
5. 5. A query to True Cache returns only committed data that's as recent as the redo apply lag.
6. 6. Each query to a True Cache instance always returns consistent data.
7. 7. True Cache improves scalability by offloading queries and reduces the number of requests to primary database.