Oracle True Cache Technical Architecture

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software, software documentation, data (as defined in the Federal Acquisition Regulation), or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed, or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software," "commercial computer software documentation," or "limited rights data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed, or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract. The terms governing the U.S. Government's use of Oracle cloud services are defined by the applicable contract for such services. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle®, Java, MySQL, and NetSuite are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc, and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

True Cache General Architecture

Notes

Oracle True Cache is an in-memory, consistent, and automatically managed SQL and key-value (object or JSON) cache for Oracle AI Database.

At a high level, here's how it works:

An application decides whether to query data from True Cache or the primary database.
True Cache satisfies queries by using data that's cached in its memory. When the data isn't in the cache, True Cache fetches the data from the primary database.
True Cache is empty when it starts up, so it reads large chunks of data to populate the cache. After a block is cached, it's updated automatically through redo apply from the primary database. This is similar to the update mechanism used in Oracle Active Data Guard.
A query to True Cache returns only committed data, and the data is always consistent.
Like all caches, the True Cache data might not be the most current data as it exists in the primary database.
If multiple True Caches exist and serve the same database application service, the listener automatically distributes and load balances sessions to each cache.

To take full advantage of True Cache, Java application developers who are using the latest JDBC Thin driver can set the primary database connection as read-only so the connection is directed automatically to True Cache. If an application isn't using the latest JDBC Thin driver, it can still benefit from True Cache by manually switching connections from True Cache to the primary database, when needed.

You can optionally deploy Oracle True Cache with Oracle AI Database Global Data Services (GDS) to manage workload routing, dynamic load balancing, and service failover across multiple True Caches and other database replicas.

This diagram illustrates a True Cache configuration with four mid-tier sessions using the JDBC Thin driver, two True Caches, and one primary database. The frequent reads go to True Cache, and infrequent reads go to the primary database.

Related Resources

Oracle True Cache

True Cache Application

Notes

When True Cache is configured, applications must decide whether to query data from True Cache or the primary database. There are two ways to do this:

The application maintains two physical connections: one to the primary database and one to True Cache. Each connection has a database application service, and the application chooses which connection to use based on whether it's reading or writing. You can use this model with any existing client drivers and any programming language.
The application sends queries that don't need to see the most current data to True Cache through a True Cache database application service. The application sends other queries and updates to the primary database through the primary database application service.
The application maintains one logical connection that uses the database application service for the primary database. The JDBC Thin driver (starting with Oracle AI Database 26ai) maintains physical connections to the primary database and True Cache. This model only works with Java applications.
The application switches from True Cache to the primary database without having to specify an instance name. The application uses special calls to flag the logical connection as read-only or read-write. If it's read-only, the query is sent to True Cache. Otherwise, it's sent to the primary database.

The JDBC method does the following:

The client application creates a logical connection to connect to the primary database application service called SALES by using the connection's useTrueCacheDriverConnection parameter.
The application flags the logical connection as setReadOnly(true) or setReadOnly(false) to direct SQL statements to True Cache or the primary database, respectively. For each logical connection, the JDBC Thin driver internally maintains two physical connections: one to the primary database and one to True Cache. Both connections were associated when the database application service SALES was created.

The JDBC method is illustrated in the following code:

static String url_primary = "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=?(ADDRESS=(PROTOCOL=tcp)(HOST=primary_host)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=sales)(SERVER=DEDICATED)))";

OracleDataSource ods1 = new oracle.jdbc.pool.OracleDataSource();

ods1.setURL(url_primary); 
ods1.setUser(user); 
ods1.setPassword(password); 

ods1.setConnectionProperty("oracle.jdbc.useTrueCacheDriverConnection","true");

Connection conn1 = ods1.getConnection();

verifyConnection(conn1); // This is connected to primary 

conn1.setReadOnly(true)

verifyConnection(conn1); // This is connected to True Cache

conn1.setReadOnly(false) 

verifyConnection(conn1); // This is connected back to primary

Related Resources

Using Oracle True Cache in Your Applications

True Cache Uniform Configuration

Notes

In a uniform configuration, you can deploy multiple, identical True Caches that use the same True Cache database application service. Client sessions are evenly distributed among True Caches, which all cache the same set of data.

This diagram shows an example of a uniform configuration with the following elements:

One primary database (PRIMDBI)
Two True Caches (TCDB1I and TCDB2I)
One remote listener (sales_rl)
Two applications

When True Cache starts, the True Cache network name that is specified in the FAL_CLIENT parameter (TCDB1I or TCDB2I) is registered with the primary database network name that is specified in the FAL_SERVER parameter (PRIMDBI).

If the application handles connections manually, it sends queries to True Cache through a True Cache database application service, and it sends other queries and updates to the primary database through the primary database application service.

To achieve more application transparency, you can use the JDBC method and associate primary database application services with True Cache database application services. This diagram shows the following database application services:

The primary database (PRIMDBI) runs one database application service called SALES.
Two True Caches (TCDB1I and TCDB2I) share one database application service called SALES_TC.

The two services are associated by setting the TRUE_CACHE_SERVICE parameter to SALES_TC for the primary database application service (SALES). The application's code only needs to know about the primary database application service (SALES). To use the SALES_TC database application service, the application changes the setReadOnly flag (TRUE or FALSE) of the SALES JDBC connection.

The True Caches and the primary database share a remote listener (sales_rl). If multiple True Caches exist and serve the same database application service, the listener automatically distributes and load balances sessions to each cache.

Related Resources

Configuring Oracle True Cache

True Cache Configuration with colocation_tag

Notes

In a partitioned configuration, the data is divided across multiple True Caches, which each cache a different subset of the data. The total size of the cached data across all True Caches can be much larger than it would be for a single primary database or a single cache in a uniform configuration.

A partitioned configuration with COLOCATION_TAG similar to the uniform configuration, except that when you set COLOCATION_TAG within the CONNECT_DATA parameter of your network alias, load balancing is ignored. The listener tries to send all connections that have the same COLOCATION_TAG to the same True Cache.

This diagram shows an example of a partitioned configuration with COLOCATION_TAG with the following elements:

One primary database (PRIMDBI)
Two True Caches (TCDB1I and TCDB2I)
One remote listener (sales_rl)
Two applications
- Sessions with COLOCATION_TAG set to US go to one True Cache (TCDB1I).
- Sessions with COLOCATION_TAG set to EUROPE go to the other True Cache (TCDB2I).

In this example, both True Caches are in the same data center. One True Cache processes all requests with the client's TNS CONNECT_DATA tagged with US (connections coming from US) and the other processes all requests with the client's TNS CONNECT_DATA tagged with EUROPE (connections coming from EUROPE).

The primary database (PRIMDBI) runs one database application service called SALES.
Two True Caches (TCDB1I and TCDB2I) share one database application service called SALES_TC.

The True Caches and the primary database share a remote listener (sales_rl).

Related Resources

Configuring Oracle True Cache

True Cache Partitioned Configuration with Multiple Services

Notes

This diagram shows an example of a partitioned configuration where each True Cache caches data for a different database application service. The diagram has the following elements:

One primary database (PRIMDBI)
Two True Caches (TCDB1I and TCDB2I)
One remote listener (sales_rl)
Two applications connected to different database application services (SALES and HR)

The primary database (PRIMDBI) runs two database application services: SALES and HR.
Two True Caches are associated with different database application services:
- TCDB1I is associated with SALES_TC.
- TCDB2I is associated with HR_TC.

The services are associated by setting the TRUE_CACHE_SERVICE parameter to SALES_TC and HR_TC for the corresponding primary database application services (SALES and HR). The application's code only needs to know about the primary database application services (SALES and HR). To use the SALES_TC and HR_TC database application services, the application changes the setReadOnly flag (TRUE or FALSE) of the SALES and HR JDBC connections.

The True Caches and the primary database share a remote listener (sales_rl).

Related Resources

Configuring Oracle True Cache

True Cache Integration with Oracle Global Data Services (GDS)

Notes

You can deploy Oracle True Cache with Oracle AI Database Global Data Services (GDS) to manage workload routing, dynamic load balancing, and service failover across multiple True Caches and other database replicas.

Global services are functionally similar to the local database application services that are provided by single instance or Oracle Real Application Clusters (Oracle RAC) databases. The main difference between global services and local services is that global services span the instances of multiple databases, whereas local services span the instances of a single database.

This diagram illustrates a basic True Cache configuration with GDS in a single region.

There is one region with two True Caches and one primary database. True Cache reads from the primary database to warm up the cache or when there's a cache miss. After a block is cached, it's updated automatically through redo apply from the primary database. Applications are configured so that frequent reads go to the True Caches and writes and infrequent reads go to the primary database.

The GDS configuration includes the following components:

The GDS catalog stores configuration data for the GDS configuration. In this example, the GDS catalog is hosted outside the primary database.
Global service managers (GSMs) provide service-level load balancing, failover, and centralized management of services in the GDS configuration. For high availability, the best practice is to include two GSMs in each region.
The GDS pool provides a common set of global services to the primary database and True Caches. A region can contain multiple GDS pools, and these pools can span multiple regions. In this example, the SALES pool provides the SALES global service for the primary database and the SALES_TC global service for the True Caches.
An Oracle Notification Service (ONS) server is located with each GSM. All ONS servers in a region are interconnected in an ONS server network. The GSMs create runtime load balancing advisories and publish them to the Oracle universal connection pool (UCP) JDBC connection pool through the ONS server network. Applications request a connection from the pool and the requests are sent to True Caches or the primary database depending on the application configuration and the GDS configuration.

Related Resources

Deploying Oracle True Cache with Oracle Global Data Services