7 TimesTen Cache

TimesTen Cache is supported in TimesTen Classic and provides the ability to transfer data between an Oracle database and a TimesTen Cache database.

You can cache data from an Oracle database in a TimesTen Cache database by creating cache groups in TimesTen where each cache group maps to a single table in the Oracle database or to a group of tables related by foreign key constraints.

This chapter includes the following topics:

Cache groups

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

TimesTen Cache supports the following features:

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

  • Cache groups can be refreshed (upload the Oracle database 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 TimesTen 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.

For full information about TimesTen Cache, see Oracle TimesTen Application-Tier Database Cache User's Guide.

Figure 7-1 illustrates the TimesTen Cache features and processes.

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 TimesTen 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 the Oracle database tables are automatically refreshed to the corresponding cache tables in the TimesTen Cache database.

  • Asynchronous writethrough (AWT) cache group - An AWT cache group enforces a caching behavior in which committed updates to cache tables in the TimesTen Cache database are automatically propagated to the corresponding the Oracle database 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 TimesTen Cache database are automatically propagated to the corresponding Oracle database 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.

If you have multiple TimesTen Cache databases, the data in cached tables is not shared among separate TimesTen Cache databases. Consequently, the content of the databases may overlap with no coordination from the TimesTen Cache unless your applications logically partition their data between different nodes or use read-only cache groups.

For more information about cache group types, see "Cache group types" in the Oracle TimesTen Application-Tier Database Cache User's Guide.

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 TimesTen Cache database.

In dynamic cache groups, cache instances are automatically loaded into the TimesTen Cache from the Oracle database when the application references cache instances that are not already in the TimesTen 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 TimesTen Cache database.

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

For more information about explicitly or dynamically loaded cache groups, see "Loading data into a cache group: Explicitly loaded and dynamic cache groups" in the Oracle TimesTen Application-Tier Database Cache User's Guide.

Transmitting data between the TimesTen Cache and an Oracle database

The TimesTen 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 the Oracle database tables

The following mechanisms are available to keep a cache group synchronized with the corresponding data in the Oracle database tables:

  • Autorefresh - An incremental autorefresh operation updates only records that have been modified in the Oracle database since the last refresh. The TimesTen Cache automatically performs the incremental refresh at specified time intervals. You can also specify a full autorefresh operation, which automatically refreshes the entire cache group at specified time intervals.

  • Manual refresh - An application issues a REFRESH CACHE GROUP statement to refresh either an entire cache group or a specific cache instance. It is equivalent to unloading and then loading the cache group or cache instance.

These mechanisms are useful under different circumstances. A full autorefresh may be the best choice if the Oracle database table is updated only once a day and many rows are changed. An incremental autorefresh is the best choice if the Oracle database table is updated often, but only a few rows are changed with each update. A manual refresh is the best choice if the application logic knows when the refresh should happen.

For more information about autorefresh or manual refresh operations for cache groups, see "Cache Group Operations" in the Oracle TimesTen Application-Tier Database Cache User's Guide.

Updating the Oracle database tables from a cache group

The propagate and flush mechanisms are available to keep the Oracle database up to date with the cache group:

  • Propagate - The most common way to propagate cache group data to the Oracle database is by using an asynchronous writethrough (AWT) cache group. Other methods of updating the Oracle database tables are using a synchronous writethrough (SWT) cache group or specifying the PROPAGATE option in a user managed cache group.

    Changes to an AWT cache group are committed without waiting for the changes to be applied to the Oracle database tables. AWT cache groups provide better response times and performance than SWT cache groups and user managed cache groups with the PROPAGATE option, but the TimesTen Cache database and the Oracle database do not always contain the same data because changes are applied to the Oracle database tables asynchronously.

    You can increase throughput from AWT cache groups to the Oracle database tables by configuring parallel replication at database creation time. You configure the number of threads for applying updates to the Oracle database tables.

  • Flush - A flush operation can be used to propagate updates manually from a user managed cache group to the Oracle database.An application initiates a flush operation by issuing a FLUSH CACHE GROUP statement. Flush operations are useful when frequent updates occur for a limited period of time over a set of records. Flush operations do not propagate deletes.

For more information about autorefresh or manual refresh operations for cache groups, see "Cache Group Operations" in the Oracle TimesTen Application-Tier Database Cache User's Guide.

Aging feature

Records can be automatically aged out of a TimesTen database, and cache instances can be automatically aged out of a TimesTen 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.

For more information about aging in cache groups, see "Implementing aging in a cache group" in Oracle TimesTen Application-Tier 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.

Passthrough feature

Applications use a single connection to a TimesTen Cache to send SQL statements to either a cache group or to the Oracle database. 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 TimesTen Cache or if it must be redirected to the Oracle database, as shown in Figure 7-2. 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 TimesTen Cache general connection attribute.

Figure 7-2 Passthrough feature

Description of Figure 7-2 follows
Description of ''Figure 7-2 Passthrough feature''

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

Replicating cache groups

You can use an active standby pair to replicate AWT cache groups and read-only cache groups. For more information about replicating cache groups, see "Cache groups and replication" in the Oracle TimesTen In-Memory Database Replication Guide.

Disaster recovery through TimesTen Cache

TimesTen Cache supports Oracle Data Guard, as well as providing its own HA capability through active standby pair replication of cache tables for read-only and AWT cache groups.

You can use the following methods to set up a disaster recovery site:

  • Replicating an AWT cache group with a subscriber propagating to an Oracle database.

    You can recover from a complete site failure by creating a special disaster recovery read-only subscriber as part of the active standby pair replication scheme. The standby database sends updates to cache group tables on the read-only subscriber. This special subscriber is located at a remote disaster recovery site and can propagate updates to a second Oracle database, also located at the disaster recovery site. The disaster recovery subscriber can take over as the active in a new active standby pair at the disaster recovery site if the primary site suffers a complete failure. Any applications may then connect to the disaster recovery site and continue operating, with minimal interruption of service.

    See "Using a disaster recovery subscriber in an active standby pair" in the Oracle TimesTen Application-Tier Database Cache User's Guide for details.

  • Using TimesTen Cache with either synchronous or asynchronous Data Guard.

    Oracle Data Guard provides the management, monitoring, and automation software infrastructure to create and maintain one or more synchronized standby Oracle databases to protect data from failures, disasters, errors, and corruptions. If the primary Oracle database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby Oracle database to the primary role, thus minimizing downtime and preventing any data loss.

    • Asynchronous Data Guard support: You can cache tables from an Oracle Active Data Guard with the asynchronous redo transport mode into read-only cache groups. The read-only cache groups are replicated within an active standby pair replication scheme. The Active Data Guard configuration includes a primary Oracle database that communicates over an asynchronous transport to a single physical standby Oracle database.

    • Synchronous Data Guard support: TimesTen Cache works with synchronous physical standby failover and switchover and logical standby switchover. During a transient upgrade, a physical standby Oracle database is transformed into a logical standby Oracle database.

    See "Using TimesTen Cache with Data Guard" in the Oracle TimesTen Application-Tier Database Cache User's Guide for details.