Oracle In-Memory Database Cache is an Oracle Database product option that includes the Oracle TimesTen In-Memory Database. It is used as a database cache at the application tier to cache Oracle data and reduce the workload on the Oracle database. It also provides the connection and transfer of data between an Oracle database and a TimesTen database, as well as facilitating the capture and processing of high-volume event flows into a TimesTen database and subsequent transfer of data into an Oracle database.
You can cache Oracle data in a TimesTen database by defining a cache grid and then creating cache groups. A cache group in a TimesTen database can cache a single Oracle table or a group of related Oracle tables.
This chapter includes the following topics:
A cache grid is a set of distributed TimesTen in-memory databases that work together to cache data from an Oracle database and guarantee cache coherence among the TimesTen databases. A grid consists of one or more in-memory database grid members that collectively manage the application data using the relational data model. The members of a grid cache data from a single Oracle database. Each grid member is backed by either a standalone TimesTen database or an active standby pair.
A standalone TimesTen database
The active master database in an active standby pair
The standby master database in an active standby pair
Thus a grid member that is a standalone database consists of one node. A grid member that is an active standby pair consists of two nodes.
Figure 1-1 shows a cache grid containing three members: two standalone TimesTen databases and an active standby pair. The grid has four nodes: the two standalone TimesTen databases, the active master database and the standby master database of the active standby pair. The read-only subscriber database is not part of the cache grid because it has no connectivity with the Oracle database. The read-only subscriber receives replicated updates from the standby master database.
In a cache grid, 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. Attaching to or detaching from the grid are online operations that do not interrupt operations on other grid members.
When requests are submitted to the grid members, the cache grid automatically redistributes data based on application access patterns. The location of the data is transparent to the application but the cache grid redistributes data dynamically to minimize access time. The cache grid automatically maintains cache coherence and transactional consistency across the grid members. You can also configure the cache grid to perform global queries without redistributing the data. See "Performing global queries on a cache grid".
TimesTen databases within a cache grid can contain explicitly loaded and dynamic cache groups, as well as local and global cache groups of any cache group type that is supported for the various cache group classifications and categories.
See "Cache group types" for details about the different types of cache groups.
See "Loading data into a cache group: Explicitly loaded and dynamic cache groups" for details about the differences between an explicitly loaded and a dynamic cache group.
See "Sharing data across a cache grid: Local and global cache groups" for details about the differences between a local and a global cache group.
See "Configuring a cache grid" for information about creating a cache grid and associating a TimesTen database with a cache grid.
Figure 1-2 shows the
target_customers cache group that caches a subset of a single Oracle table
In a cache group with multiple tables, each child table must reference the root table or another child table in the same cache group using a foreign key constraint. Although tables in a multiple-table cache group must be related to each other in the TimesTen database through foreign key constraints, the corresponding tables do not necessarily need to be related to each other in the Oracle database. The root table does not reference any table with a foreign key constraint. See "Multiple-table cache group" for more details about the characteristics of a multiple-table cache group.
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
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
The three rows with the value
65432 in the
ord_num column of the
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
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 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 "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.
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 instance" 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.
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.
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.
You can configure Oracle In-Memory Database Cache to achieve high availability of cache tables, and facilitate failover and recovery while maintaining connectivity to the Oracle database. A TimesTen database that is a participant in an active standby pair replication scheme can provide high availability for cache tables in a read-only or an AWT cache group.
An active standby pair provides for high availability of a TimesTen database. Multiple grid members provide for high availability of a TimesTen cache grid. Oracle Real Application Clusters (Oracle RAC) and Data Guard provides for high availability of an Oracle database.
See "Replicating cache tables" for information on configuring replication of cache tables.
See "Using Oracle In-Memory Database Cache in an Oracle RAC Environment" for more information on Oracle In-Memory Database Cache and Oracle RAC.
See "Using Oracle In-Memory Database Cache with Data Guard" for more information on Oracle In-Memory Database Cache and Data Guard.