1 Oracle In-Memory Database Cache Concepts

Cache instance

Data is loaded from an Oracle database into a cache group within a TimesTen database in units called cache instances. A cache instance is defined as a single row in the cache group's root table together with the set of related rows in the child tables.

Figure 1-3 shows three tables in the customer_orders cache group. The root table is customer. orders and order_item are child tables. The cache instance identified by the row with the value 122 in the cust_num primary key column of the customer table includes:

• The two rows with the value 122 in the cust_num column of the orders table (whose value in the ord_num primary key column is 44325 or 65432), and

• The three rows with the value 44325 or 65432 in the ord_num column of the order_item table

Figure 1-3 Multiple-table cache group

Description of "Figure 1-3 Multiple-table cache group"

Cache group types

The most commonly used types of cache groups are:

• Read-only cache group

  A read-only cache group enforces a caching behavior in which committed updates on cached tables in the Oracle database are automatically refreshed to the cache tables in the TimesTen database. Using a read-only cache group is suitable for reference data that is heavily accessed by applications.

  See "Read-only cache group" for details about read-only cache groups.

• Asynchronous writethrough (AWT) cache group

  An AWT cache group enforces a caching behavior in which committed updates on cache tables in the TimesTen database are automatically propagated to the cached tables in the Oracle database in asynchronous fashion. Using an AWT cache group is suitable for high speed data capture and online transaction processing.

  See "Asynchronous writethrough (AWT) cache group" for details about AWT cache groups.

Other types of cache groups include:

• Synchronous writethrough (SWT) cache group

  An SWT cache group enforces a caching behavior in which committed updates on cache tables in the TimesTen database are automatically propagated to the cached tables in the Oracle database in synchronous fashion.

  See "Synchronous writethrough (SWT) cache group" for details about SWT cache groups.

• User managed cache group

  A user managed cache group defines customized caching behavior.

  For example, you can define a cache group that does not use automatic refresh nor automatic propagation where committed updates on the cache tables are manually propagated or flushed to the cached Oracle tables.

  You can also define a cache group that uses both automatic propagation in synchronous fashion on every table and automatic refresh.

  See "User managed cache group" for details about user managed cache groups.

Transmitting updates between the TimesTen and Oracle databases

Transmitting committed updates between the TimesTen cache tables and the cached Oracle tables keeps these tables in the two databases synchronized.

As shown in Figure 1-4, propagate or flush are operations that transmit committed updates on cache tables in the TimesTen database to the cached tables in the Oracle database. Flush is a manual operation and propagate is an automatic operation.

Load, refresh or automatic refresh are operations that transmit committed updates on cached tables in the Oracle database to the cache tables in the TimesTen database. Load and refresh are manual operations, and automatic refresh is an automatic operation.

See "Flushing a user managed cache group" for information about the FLUSH CACHE GROUP statement which can only be issued on a user managed cache group.

See "Asynchronous writethrough (AWT) cache group" and "Synchronous writethrough (SWT) cache group" for details about how a propagate operation is processed on AWT and SWT cache groups, respectively.

See "Loading and refreshing a cache group" for information about the LOAD CACHE GROUP and REFRESH CACHE GROUP statements.

See "AUTOREFRESH cache group attribute" for details about an automatic refresh operation.

Figure 1-4 Transmitting committed updates between the TimesTen and Oracle databases

Description of "Figure 1-4 Transmitting committed updates between the TimesTen and Oracle databases"

Loading data into a cache group: Explicitly loaded and dynamic cache groups

Cache groups are categorized as either explicitly loaded or dynamic.

In an explicitly loaded cache group, cache instances are loaded manually into the TimesTen cache tables from Oracle using a load or refresh operation, or automatically using an automatic refresh operation. The cache tables are loaded before operations such as queries are performed on the tables. An explicitly loaded cache group is appropriate when the set of data to cache is static and can be predetermined before applications begin performing operations on the cache tables. By default, cache groups are explicitly loaded unless they are defined as dynamic.

In a dynamic cache group, cache instances are loaded into the TimesTen cache tables on demand from Oracle using a dynamic load operation, or manually using a load operation. A manual refresh or an automatic refresh operation on a dynamic cache group can result in existing cache instances being updated or deleted, but committed updates on Oracle data that are not being cached do not result in new cache instances being loaded into its cache tables. A dynamic cache group is appropriate when the set of data to cache is small and should not be preloaded from Oracle before applications begin performing operations on the cache tables.

See "Transmitting updates between the TimesTen and Oracle databases" for details about cache group load and refresh operations.

See "Loading and refreshing a cache group" for more details about the differences between performing a load and a refresh operation on an explicitly loaded cache group, and performing the same operations on a dynamic cache group.

See "Dynamically loading a cache group" for details about a dynamic load operation.

Any cache group type (read-only, AWT, SWT, user managed) can be defined as an explicitly loaded cache group. All cache group types except a user managed cache group that uses both the AUTOREFRESH cache group attribute and the PROPAGATE cache table attribute can be defined as a dynamic cache group.

See "Dynamic cache groups" for more information about dynamic cache groups.

Sharing data across a cache grid: Local and global cache groups

In addition to being explicitly loaded or dynamic, cache groups are also classified as either local or global.

In a local cache group, data in its cache tables are not shared across TimesTen databases even if the databases are members of the same cache grid. Therefore, the databases can have overlapping data because the cache instances are local to a specific grid member. Committed updates on the TimesTen cache tables are propagated to the cached Oracle tables without coordination with other grid members. Any cache group type can be defined as a local cache group. A local cache group can be defined either as explicitly loaded or dynamic. Using a local cache group is suitable for reference data that is read frequently and can be present in all grid members, and for disjoint data that is logically partitioned for optimal concurrency and throughput. By default, cache groups are local unless they are defined as global.

In a global cache group, data in its cache tables are shared across TimesTen databases that are members of the same cache grid. Committed updates to the same data on different grid members are propagated to Oracle in the order in which they were issued within the grid to ensure read/write data consistency across the members of the grid.

A dynamic AWT cache group and an explicitly loaded AWT cache group can be defined as global cache groups. 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.Using a global cache group is suitable for updatable data that can only be accessed by or present in one grid member at a time in order to ensure that the data is consistent among both the members of the grid and the Oracle database.

See "Global cache groups" for information about creating and using a global cache group.

Summary of cache group types

The table in Figure 1-5 summarizes the valid combinations of cache group types, categories and classifications available to the user at cache group creation time. The cache group categories determine how the data is loaded into the cache group. The cache group classifications determine whether data in the cache group can be shared across a cache grid.

You can create an explicitly loaded local cache group or a dynamic local cache group of any cache group type. You can create a global cache group for a cache group whose category and type is dynamic AWT or explicitly loaded AWT.

Figure 1-5 Summary of cache group types and categories

Description of "Figure 1-5 Summary of cache group types and categories"