TimesTen - Cache Group

Timesten Component

About

A cache group is a collection of one or more cached Oracle tables:

  • related to each other by foreign key constraints.
  • arranged in a logical hierarchy by using primary key and foreign key relationships.

Data from the Oracle database can be preloaded into a cache group. Depending on the cache group type, an optional WHERE condition can also be specified to restrict or partition the data to be cached.

You can create or modify cache groups by using SQL statements or by using Oracle SQL Developer.

Changes that originate in the Oracle tables are refreshed into the cache by the cache agent.

An Oracle table cannot be cached in separate cache groups within the same TimesTen database. However, the table can be cached in separate cache groups within different TimesTen databases.

Timesten Cache Group Attribute

Timesten Cache Group Add Table

Features

Cache groups support these features:

  • Applications can read from and write to cache groups.
  • Cache groups can be refreshed from Oracle data automatically or manually.
  • Updates to cache groups can be propagated to Oracle tables automatically or manually.
  • Changes to either Oracle tables or the cache group can be tracked automatically.

IMDB Cache is designed to continue running even after the Oracle Database server or network connection has been lost. Committed transactions to the cache database are tracked and persisted in the transaction log; and once the connection to the Oracle Database is restored, the transactions are propagated to the Oracle Database. Similarly, committed transactions on the source tables in the Oracle Database are tracked and refreshed to the TimesTen database once connection between the databases is re-established.

Table

Each table in a cache group is related to an Oracle database table. A cache table can contain all rows and columns or a subset of the rows and columns in the related Oracle table.

Cache group properties

Dynamic

The data in a dynamic cache group is loaded on demand.

For example, a call center application may not want to preload all of its customers' information into TimesTen as it may be very large. Instead it can use a dynamic cache group so that a specific customer's information is loaded only when needed such as when the customer calls or logs onto the system.

Any system managed cache group type (read-only, AWT, SWT) can be defined as a dynamic cache group. A user managed cache group can be defined as a dynamic cache group unless it uses both the AUTOREFRESH cache group attribute and the PROPAGATE cache table attribute.

Global

Tables that are cached in separate cache groups within different TimesTen databases must be cached in global cache groups in order for the cache grid to manage consistency of the cache instances across the grid members when updates are committed on the cache tables of the cache group.

Global cache groups can be defined as dynamic AWT cache groups or as explicitly loaded AWT cache groups.

Type

When rows in a cache group are updated by applications, the corresponding rows in Oracle tables can be updated:

The asynchronous configuration produces significantly higher throughput and much faster application response times.

Applications using IMDB Cache may choose to configure a combination of caching options:

Read-only

Read-only cache group specifies the tables cached from the Oracle database are for read operations, updates are done in the Oracle database and refreshed to the cache.

transactions are performed in the Oracle Database and the changes are refreshed to the TimesTen cache database.

For read-only caches, incremental updates in the Oracle Database are asynchronously refreshed to the in-memory cache tables in the application-tier at user-specified intervals.

CREATE READONLY CACHE GROUP "READ_ONLY" 
 AUTOREFRESH MODE INCREMENTAL INTERVAL 5 SECONDS
 STATE PAUSED
 FROM
  "DI_BISAMPLE"."SAMP_CUSTOMERS_D" (
    "CUST_KEY"           NUMBER             NOT NULL,
    "NAME"               VARCHAR2(255 CHAR),
    "TYPE_KEY"           VARCHAR2(255 CHAR),
    "FST_CONTACT_DT"     DATE              ,
    "SEGMENT_KEY"        NUMBER            ,
    "INCOME_LVL"         VARCHAR2(255 CHAR),
    "STATUS_KEY"         VARCHAR2(255 CHAR),
    "LST_ORDER_DT"       DATE              ,
    "ADDRESS_KEY"        NUMBER            ,
    "MARITAL_ST"         VARCHAR2(20 BYTE) ,
    "PREV_MARITAL_ST"    VARCHAR2(20 BYTE) ,
    "PREV_MARITAL_ST_DT" DATE              ,
    "BIRTH_DT"           DATE              ,
    "CRDT_RATE"          NUMBER(38)        ,
    "GENDER"             VARCHAR2(20 BYTE) ,
    "LTV"                NUMBER            ,
    "NUM_ATTRIBUTE"      NUMBER            ,
    PRIMARY KEY("CUST_KEY")
  )

Read-write (or write-through)

Transactions are performed in the TimesTen cache database and then propagated to the Oracle Database.

AWT

Asynchronous Write-through cache group specifies the tables cached from the Oracle database are for read/write transactions in the cache, committed transactions are asynchronously propagated to the Oracle database.

Any updates that occur in the TimesTen cache table are automatically propagated to the Oracle database.

To enable the propagation of AWT data between the cache tables and the Oracle database, the replication agent must be running.

Asynchronous write-through cache leverages the speed of TimesTen by first committing the transactions locally in the cache database, and asynchronously sending the updates to the Oracle Database. Asynchronous write-through cache groups provide faster application response time and higher transaction throughput.

SWT

Synchronous write-through cache will ensure that if the Oracle Database cannot accept the update(s), the transaction is rolled back from the cache database; with synchronous write-through, the application must wait for the commits to complete in both the Oracle Database and the TimesTen database.

On-demand and preloaded cached

Data may be loaded on-demand or preloaded, and may be shared across the cache grid members, or reside only in a specific cache node.

Note

Automatic refresh

An automatic refresh cache group refers to a read-only cache group or a user managed cache group that uses the AUTOREFRESH MODE INCREMENTAL cache group attribute.

Support

Creating a cache group requires that the cache admin user be set

Creating a cache group requires that the cache admin user be set.
Please set it before trying to create a cache group.

When you try to create a cache group with a TT user, you have to set the cache admin user for this user.

Documentation / Reference





Discover More
Timesten   Cache Grid Relation With Oracle And Tt Database
Timesten - Cache Grid

A TimesTen cache grid provides a means to horizontally scale out cache groups across multiple systems with: read and write data consistency across the TimesTen databases and predictable latency for...
Timesten Timesten Schema
Timesten - Cache Repository (Oracle Objects)

The cache repository is split in two schema: the timesten schema and the cache administration schema The Timesten schema stores information in order to manage a cache grid. Other objects...
Timesten Component
Timesten - How to set up the Timesten Cache ?

Steps to set up the Timesten Cache to cache data of an Oracle Database. Before you cache Oracle data in a TimesTen database, you must perform certain tasks: either outside SQL Developer using command-line...
Times Ten Cache Grid
Timesten - IMDB Cache (Cache Oracle Table)

“”“” IMDB Cache improves application transaction response time, by caching a performance-critical subset of tables from an Oracle database into a TimesTen in-memory database running in theapplication...
Timesten Component
Timesten - Replication (High Availability, Workload distribution)

TimesTen replication enables to achieve: (near-continuous|High) availability or workload distribution by replicating transactions between IMDB TimesTen databases. Type of replication Asynchronous...



Share this page:
Follow us:
Task Runner