8 IMDB Cache

Cache grid

A cache grid is a collection of IMDB Cache databases that collectively manage the application data. A cache grid consists of one or more grid members that are each backed by an IMDB Cache database. Grid members cache tables from a central Oracle database or Real Application Cluster (Oracle RAC). Cached data is dynamically distributed across multiple grid members without shared storage. This architecture allows the capacity of the cache grid to scale based on the processing needs of the application. When the workload increases or decreases, new grid members attach to the grid or existing grid members detach from the grid without interrupting operations on other grid members.

An IMDB Cache database within a cache grid can contain explicitly loaded and dynamic cache groups as well as global and local cache groups of any cache group type. A cache grid ensures that data is consistent across nodes.

Figure 8-1 shows a cache grid. The grid has three members: two standalone IMDB Cache databases and an active standby pair with a read-only subscriber. The read-only subscriber is not part of the grid.

Figure 8-1 Cache grid

Description of "Figure 8-1 Cache grid"

Cache groups

You can cache Oracle data by creating a cache group in an IMDB Cache database. A cache group can be created to cache a single Oracle table or a set of related Oracle tables. The cached Oracle data can consist of all the rows and columns or a subset of the rows and columns in the Oracle tables.

IMDB Cache supports the following features:

• Applications can both read from and write to cache groups.

• Cache groups can be refreshed (bring Oracle data into the cache group) automatically or manually.

• Cache updates can be sent to the Oracle database automatically or manually. The updates can be sent synchronously or asynchronously.

The IMDB Cache database interacts with the Oracle database to perform all of the synchronous cache group operations, such as creating a cache group and propagating updates between the cache group and the Oracle database. A process called the cache agent performs asynchronous cache operations, such as loading data into the cache group, manually refreshing the data from the Oracle database to the cache group, and automatically refreshing the data from the Oracle database to the cache group.

Figure 8-2 illustrates the IMDB Cache features and processes.

Figure 8-2 IMDB Cache

Description of "Figure 8-2 IMDB Cache"

Each cache group has a root table that contains the primary key for the cache group. Rows in the root table may have one-to-many relationships with rows in child tables, each of which may have one-to-many relationships with rows in other child tables.

A cache instance is the set of rows that are associated by foreign key relationships with a particular row in the root table. Each primary key value in the root table specifies a cache instance. Cache instances form the unit of cache loading and cache aging. No table in the cache group can be a child to more than one parent in the cache group. Each IMDB Cache record belongs to only one cache instance and has only one parent in its cache group.

The most commonly used cache group types are:

• Read-only cache group - A read-only cache group enforces a caching behavior in which committed updates to Oracle tables are automatically refreshed to the corresponding cache tables in the IMDB Cache database.

• Asynchronous writethrough (AWT) cache group - An AWT cache group enforces a caching behavior in which committed updates to cache tables in the IMDB Cache database are automatically propagated to the corresponding Oracle tables asynchronously.

Other types of cache groups are:

• Synchronous writethrough (SWT) cache group - An SWT cache group enforces a caching behavior in which committed updates to cache tables in the IMDB Cache database are automatically propagated to the corresponding Oracle tables synchronously.

• User managed cache group - A user managed cache group defines customized caching behavior. For example, individual cache tables in a user managed cache are not constrained to be all of the same type. Some tables may be defined as read-only while others may be defined as updatable.

Dynamic cache groups and explicitly loaded cache groups

Cache groups can be either dynamically loaded or explicitly loaded.

In explicitly loaded cache groups, the application preloads data into the cache tables from the Oracle database using a load cache group operation. From that point on, all data needed by the application is available in the IMDB Cache database.

In dynamic cache groups, cache instances are automatically loaded into the IMDB Cache from the Oracle database when the application references cache instances that are not already in the IMDB Cache. The use of dynamic cache groups is typically coupled with least recently used (LRU) aging so that less recently used cache instances are aged out of the cache to free up space for recently used cache instances. Using dynamic cache groups is appropriate when the size of the data that qualifies for caching exceeds the size of the memory available for the IMDB Cache database.

All cache group types (read-only, AWT, SWT, user managed) can be defined as a explicitly loaded or dynamic.

Global and local cache groups

Cache groups can be defined as either local or global.

In local cache groups, data in the cached tables is not shared among IMDB Cache databases even if the databases are members of the same cache grid. Consequently, the content of the databases may overlap with no coordination from the IMDB Cache. Local cache groups are appropriate for applications that have logically partitioned their data between different nodes or for read-only cache groups. Any cache group type can be defined as a local cache group. Local cache groups can be explicitly loaded or dynamic.

In global cache groups, data in the cached tables is shared among IMDB Cache databases within the same cache grid. Updates to the same data by different grid members are coordinated by the grid to ensure read/write data consistency across the IMDB Caches.

A dynamic AWT cache group and an explicitly loaded AWT cache group can be defined as a global cache group. New cache instances are loaded into the cache tables of a global cache group on demand. Queries on a dynamic AWT global cache group can be satisfied by data from the local grid member on which the query is made, from remote grid members or from the Oracle database. Queries on an explicitly loaded AWT cache group can be satisfied by data from the local grid member or from remote grid members

Transmitting data between the IMDB Cache and Oracle Database

The IMDB Cache maintains consistency between cached data and the Oracle database by automatically propagating updates from cache groups to the Oracle database and automatically refreshing data in cache groups from the Oracle database.

The rest of this section includes the following topics:

• Updating a cache group from Oracle tables

• Updating Oracle tables from a cache group

Aging feature

Records can be automatically aged out of a TimesTen database, and cache instances can be automatically aged out of an IMDB Cache database. Aging can be usage-based or time-based.You can configure both usage-based and time-based aging in the same system, but you can define only one type of aging on a specific cache group.

Dynamic load can be used to reload a requested cache instance that has been deleted by aging.

Passthrough feature

Applications can send SQL statements to either a cache group or to the Oracle database through a single connection to an IMDB Cache. This single-connection capability is enabled by a passthrough feature that checks whether the SQL statement can be handled locally by the cached tables in the IMDB Cache or if it must be redirected to the Oracle database, as shown in Figure 8-3. The passthrough feature provides settings that specify what types of statements are to be passed through and under what circumstances. The specific behavior of the passthrough feature is controlled by the PassThrough IMDB Cache general connection attribute.

Figure 8-3 Passthrough feature

Description of "Figure 8-3 Passthrough feature"

Replicating cache groups

You can use an active standby pair to replicate AWT cache groups and read-only cache groups.

You can recover from a complete failure of a site by creating a special disaster recovery read-only subscriber as part of the active standby pair configuration. This special subscriber, located at a remote disaster recovery site, can propagate updates to a second Oracle database, also located at the disaster recovery site.

For more information

For more information about IMDB Cache, see Oracle In-Memory Database Cache User's Guide.

For more information about aging in cache groups, see "Implementing aging on a cache group" in Oracle In-Memory Database Cache User's Guide. For information about aging in tables that are not in cache groups, see "Implementing aging in your tables" in Oracle TimesTen In-Memory Database Operations Guide.

For more information about the passthrough feature, see "Setting a passthrough level" in Oracle In-Memory Database Cache User's Guide.

For more information about replicating cache groups, see "Cache groups and replication" in Oracle TimesTen In-Memory Database TimesTen to TimesTen Replication Guide.