Skip Headers
Oracle® In-Memory Database Cache User's Guide
Release 11.2.1

Part Number E13073-13
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

What's New

This section summarizes the new features of Oracle In-Memory Database Cache release 11.2.1 that are documented in this guide and provides links to more information.

New features in Release 11.2.1.9.0

In a dynamic cache group, the data in its cache tables can be loaded on demand or manually. While dynamic cache groups have been around for several releases, in this release the dynamic cache group functionality has been expanded to include joins across tables that exist in multiple cache groups. For full details, see "Dynamically loading a cache instance".

New features in Release 11.2.1.7.0

You can create an explicitly loaded global cache group. See "Explicitly loaded global cache groups".

You can use the ttRepStateGet built-in procedure to return the grid state as well as the database role after failover in an active standby pair grid member. See "Recovering after failure of a grid node".

New features in Release 11.2.1.6.0

You can perform a global query on cache tables and noncache tables across all nodes in a cache grid. See "Performing global queries on a cache grid".

You can unload a cache group on all grid members by specifying a global unload operation. See "Unloading a cache group across all grid members".

New features in Release 11.2.1.5.0

You can cache Oracle CLOB, BLOB and NCLOB data as TimesTen VARCHAR2, VARBINARY or NVARCHAR2 data. See "Caching Oracle LOB data".

New features in Release 11.2.1.4.0

This section summarizes the new features of Oracle In-Memory Database Cache that are documented in this guide.

New features in Release 11.2.1.1.0

This section summarizes the new features of Oracle In-Memory Database Cache that are documented in this guide.

Cache grid

By default, you must create a cache grid to cache Oracle data in TimesTen databases. A cache grid provides read and write consistency on the cache tables among the TimesTen databases within the grid.

See "Configuring a cache grid" for information about defining a cache grid on one or more TimesTen databases.

Global cache group

Creating a global cache group allows data in its cache tables to be shared across multiple TimesTen databases within a cache grid. Only a dynamic asynchronous writethrough (AWT) cache group can be defined as a global cache group.

See "Global cache groups" for details about creating a global cache group.

With a local cache group, data in its cache tables are not shared across TimesTen databases regardless of whether the databases are members of the same cache grid. Any cache group type and category can be defined as a local cache group.

Dynamic cache group

In a dynamic cache group, the data in its cache tables can be loaded on demand or manually. You can create a dynamic cache group for nearly any cache group type and classification.

See "Dynamic cache groups" for details about creating a dynamic cache group.

See "Dynamically loading a cache instance" for details about loading data into a dynamic cache group's cache tables.

With an explicitly loaded cache group, data is manually or automatically loaded into its cache tables. Any cache group type and classification can be defined as an explicitly loaded cache group.

Monitoring DDL operations on Oracle tables

You can enable tracking of DDL operations performed on Oracle tables that are cached in a TimesTen database. Tracking DDL operations on cached Oracle tables can be useful for monitoring or troubleshooting purposes.

See "Tracking DDL statements issued on cached Oracle tables" for details about enabling tracking of DDL operations on Oracle tables.

Recovering cache groups after failed automatic refresh operations

If a TimesTen database contains automatic refresh cache groups and the cache agent is not running on the database, automatic refresh operations are attempted, by default, but fail on those cache groups within that database. The failed automatic refresh attempts impacts the performance of automatic refresh operations on cache groups in other TimesTen databases that cache data from the same Oracle database.

Note:

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.

See "Impact of failed automatic refresh operations on TimesTen databases" for details about reducing the performance degradation in this situation and recovering the cache groups which failed to be automatically refreshed.

Monitoring the cache administration user's tablespace usage

You can configure an action to occur when the cache administration user's tablespace becomes full. For automatic refresh cache groups, change log tables are created in the cache administration user's tablespace. When an update operation is issued on an Oracle table that is cached in one of these cache groups, the configured action is performed when there is no space available in the cache administration user's tablespace to insert a new row into the change log table.

See "Monitoring the cache administration user's tablespace" for details about the configured actions, and how to return a warning to the application when the cache administration user's tablespace usage exceeds a configured threshold.