1 Overview for the Oracle TimesTen In-Memory Database

Oracle TimesTen In-Memory Database (TimesTen) is a relational database that is memory-optimized for fast response and throughput. You can create one or more in-memory, SQL relational, ACID-complaint databases. The database resides entirely in memory at runtime and is persisted to disk storage for the ability to recover and restart.

  • Oracle TimesTen In-Memory Database in classic mode (TimesTen Classic) is a memory-optimized relational database that provides applications with the responsiveness and high throughput. High availability for the in-memory database is provided through transactional replication.

  • Oracle TimesTen In-Memory Database in grid mode (TimesTen Scaleout) is a grid of interconnected hosts running TimesTen Scaleout instances that work together to provide fast access, fault tolerance, and high availability for in-memory data. K-safety provides fault tolerance by enabling you to define the number of copies of data to ensure that your database continues to operate in spite of various faults (as long as a single copy of the data is accessible). A grid contains one or more databases and each database is distributed across all instances of the grid.

  • Oracle TimesTen Application-Tier Database Cache (TimesTen Cache) is an Oracle Database product option ideal for caching performance-critical subsets of an Oracle database for improved response time in the application tier. Cache tables can be read-only or updatable. Applications read and update the cache tables using standard SQL, and data synchronization between the cache and the Oracle database is performed automatically. TimesTen Application-Tier Database Cache offers applications the full generality and functionality of a relational database, the transparent maintenance of cache consistency with the Oracle database, and the high performance of an in-memory database.

The following sections provide an overview for TimesTen:

TimesTen database performance overview

Much of the work that is done by a conventional, disk-optimized RDBMS is done under the assumption that data primarily resides on disk. Optimization algorithms, buffer pool management, and indexed retrieval techniques are designed based on this fundamental assumption.

Even when a disk-based RDBMS has been configured to hold all of its data in main memory, its performance is limited by assumptions of disk-based data residency. These assumptions cannot be easily reversed because they are hard-coded in processing logic, indexing schemes, and data access mechanisms.

TimesTen is designed with the knowledge that data resides in main memory and can take more direct routes to data, reducing the length of the code path and simplifying algorithms and structure.

When the assumption of disk-residency is removed, complexity is dramatically reduced. The number of machine instructions drops, buffer pool management disappears, extra data copies are not needed, index pages shrink, and their structure is simplified. The design becomes simple and more compact, and requests are executed faster. Figure 1-1 shows the simplicity of the TimesTen design.

Figure 1-1 Comparing a disk-based RDBMS to TimesTen Classic

Description of Figure 1-1 follows
Description of ''Figure 1-1 Comparing a disk-based RDBMS to TimesTen Classic''

TimesTen Scaleout, TimesTen Classic, and TimesTen Cache all deliver high performance since they all use the Oracle TimesTen In-Memory Database as their RDBMS. TimesTen Scaleout provides the best throughput; TimesTen Classic provides the best latency. The TimesTen in-memory database delivers high performance by changing the assumptions about where data resides at runtime. The TimesTen in-memory database manages data in memory and optimizes data structures and access algorithms accordingly. Thus, database operations execute with maximum efficiency, achieving dramatic gains in responsiveness and throughput, even compared with a fully cached, disk-based relational database management system (RDBMS).

TimesTen In-Memory Database general feature overview

Unless otherwise indicated, TimesTen Scaleout, TimesTen Classic, and TimesTen Cache have the same database features.

TimesTen API and language support

TimesTen supports:

  • Industry standard language for RDBMS: SQL.

  • Industry standard APIs: ODBC, JDBC, and ODP.NET.

  • Oracle APIs: PL/SQL, Oracle Call Interface (OCI), and ProC/C++.

  • TTClasses and built-in procedures provided by TimesTen that extend ODBC functionality for TimesTen-specific operations.

  • Open source programming languages, such as Python and Node.js.

The runtime architecture of TimesTen supports connectivity through the ODBC, JDBC, OCI, Pro*C/C++ Precompiler and ODP.NET APIs.

SQL and PL/SQL functionality

TimesTen supports extensive SQL functionality to simplify the configuration and management of special features. Using SQL to shield applications from system internals enables a database to be altered or extended without impacting existing applications. New services can be quickly added into a production environment simply by adding application modules, tables, and columns. Any developer familiar with the Oracle database or SQL interfaces can be immediately productive developing applications with TimesTen. For more information, see the Oracle TimesTen In-Memory Database SQL Reference.

TimesTen supports Oracle PL/SQL (Procedural Language Extension to SQL), a programming language that enables you to integrate procedural constructs with SQL for a TimesTen in-memory database. You can execute PL/SQL from all supported APIs. For more information, see the Oracle TimesTen In-Memory Database PL/SQL Developer's Guide.

OCI, ODBC and JDBC interfaces

TimesTen supports the Oracle Call Interface (OCI) for TimesTen functionality.

TimesTen OCI support enables you to run many existing OCI applications with TimesTen in direct mode or client/server mode. TimesTen OCI also enables you to use other Oracle Database products that use OCI as a database interface. You can call PL/SQL from OCI applications.

TimesTen also supports the industry standard ODBC and JDBC API interfaces. TimesTen supports versions of these APIs that are both fully compliant with the standards and tuned for maximum performance in the TimesTen environment.

Unlike many other database systems, where the ODBC API support may be much slower than the proprietary interface, ODBC is a native TimesTen interface that operates directly with the database engine.

For more information, see Oracle TimesTen In-Memory Database C Developer's Guide and Oracle TimesTen In-Memory Database Java Developer's Guide.

Pro*C/C++ Precompiler support

TimesTen supports the Oracle Pro*C/C++ Precompiler for C and C++ applications. You can use the precompiler with embedded SQL and PL/SQL applications that access a TimesTen database. Further, you can use your C or C++ program host variables in your embedded SQL or PL/SQL. For more information, see Oracle TimesTen In-Memory Database C Developer's Guide.

ODP.NET support

Oracle Data Provider for .NET (ODP.NET) is an implementation of the Microsoft ADO.NET interface. ODP.NET support for TimesTen provides fast and efficient ADO.NET data access from .NET and C# client applications to a TimesTen in-memory database.

For more information, see Oracle Data Provider for .NET Oracle TimesTen In-Memory Database Support User's Guide.

Open source programming languages

TimesTen supports open source programming languages, Python and Node.js, to access any TimesTen database through the Oracle Database ODPI-C driver.

ODPI-C is an open source library from Oracle Corporation designed to simplify access to Oracle databases from a variety of programming languages. It is a layer on top of the Oracle Call Interface.

See the Oracle TimesTen In-Memory Database Open Source Languages Support Guide for more details.

TTClasses

TimesTen C++ Interface Classes (TTClasses) is more convenient than ODBC while maintaining fast performance. This C++ class library provides wrappers around the most common ODBC functionality. The TTClasses library is also intended to promote best practices when writing application software.

For more information, see Oracle TimesTen In-Memory Database TTClasses Guide.

Transactional ACID compliance

TimesTen supports transactions that provide atomic, consistent, isolated and durable (ACID) access to data. All operations on a TimesTen database, even those that do not modify or access application data, are executed within a transaction. For more information, see "Transaction isolation", "Durability" in this guide and "Transaction Management" in the Oracle TimesTen In-Memory Database Operations Guide.

Durability

A database in TimesTen is persistent across power failures and crashes. TimesTen accomplishes durability by periodically writing to disk:

  • Changes made by transactions through transaction log files.

    Transaction log records are written to disk asynchronously or synchronously to the completion of the transaction and controlled by the application at the transaction level. For systems where maximum throughput is paramount, such as non-monetary transactions within network systems, asynchronous logging enables extremely high throughput with minimal exposure. In cases where data integrity must be preserved, such as securities trading, TimesTen ensures complete durability, with no loss of data. See "Transaction logging" and "When are transaction log files deleted?" for more details.

  • All data through checkpoint files.

    TimesTen maintains the disk-resident version of the database with a checkpoint operation that takes place in the background and has very little impact on database applications. This operation is performed automatically. TimesTen maintains two checkpoint files in case a failure occurs mid-checkpoint. Checkpoint files should reside on disks separate from the transaction logs to minimize the impact of checkpointing on application activity. See "Checkpointing" for more details.

Durability for TimesTen Classic

TimesTen Classic uses the transaction log in the following situations:

  • Recover transactions if the application or database fails

  • Undo transactions that are rolled back

  • Replicate changes to other TimesTen databases

  • Replicate TimesTen changes to Oracle Database tables

  • Enable applications to detect changes to tables (using the XLA API)

Durability for TimesTen Scaleout

In TimesTen Scaleout, the data in your database is distributed into elements. Each element keeps its own checkpoint and transaction log files. As a result, the data stored in each element is independently durable. Each instance in a grid manages one element of a database. In the event of a failure, an instance can automatically recover the data stored in its element from the checkpoint and transaction logs files while the remaining instances continue to service applications.

TimesTen Scaleout also enables you to keep multiple copies of your data to increase durability and fault tolerance.

You can change the durability settings of a database according to your performance and data durability needs. For example, you may choose if data is flushed to disk with every commit or periodically in batches in order to operate at a higher performance level.

See "Durability settings" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more details.

Performance through query optimization

As with any mainstream RDBMS, a cost-based optimizer automatically determines the fastest way to process queries and transactions. TimesTen has a cost-based query optimizer that chooses the best query execution plan based on factors such as the presence of indexes, the cardinality of tables, and the presence of ORDER BY clauses in the query.

The method that the TimesTen optimizer analyzes SQL statements to minimize performance costs is different than in traditional disk-based systems, because the cost structure of a main-memory system differs from that of disk-based systems in which disk access is a dominant cost factor. Because disk access is not a factor in TimesTen, the optimization cost model includes factors not usually considered by optimizers for disk-based systems, such as the cost of evaluating predicates.

TimesTen provides range and hash indexes. The query optimizer also uses two types of join methods (nested-loop and merge-join). The optimizer can create temporary indexes as needed. The optimizer accepts hints that provide applications the decision on whether to make tradeoffs between factors, such as temporary space usage and performance.

See Chapter 5, "Query Optimization" for more information about the query optimizer and indexing techniques.

Concurrency

TimesTen provides full support for shared databases. Options are available so users can choose the optimum balance between response time, throughput and transaction semantics for an application.

Read-committed isolation provides nonblocking operations and is the default isolation level. For databases with extremely strict transaction semantics, serializable isolation is available. These isolation levels conform to the ODBC standard and are implemented with optimal performance in mind. As defined by the ODBC standard, a default isolation level can be set for a TimesTen database, which can be dynamically modified for each connection at runtime.

See Chapter 4, "Concurrent Operations" for more information about managing concurrent operations in TimesTen.

Database character sets and globalization support

TimesTen provides globalization support for storing, retrieving, and processing data in native languages. Over 50 different national, multinational, and vendor-specific character sets including the most popular single-byte and multibyte encodings, plus Unicode, are supported as the database storage character set. TimesTen Cache supports some database character sets that are compatible with the Oracle Database. The connection character set can be defined to enable an application running in a different encoding to communicate to a TimesTen database; character set conversion between the application and the database occurs automatically and transparently.

TimesTen offers linguistic sorting capabilities that handle the complex sorting requirements of different languages and cultures. More than 80 linguistic sorts are provided. They can be extended to enable the application to perform case-insensitive and accent-insensitive sorting and searches.

For more information, see "Globalization Support" in Oracle TimesTen In-Memory Database Operations Guide.

Database connectivity

TimesTen supports direct and client/server connection options so that users can choose the best tradeoff between performance and functionality for their applications.

  • A direct connection connects an application to a database where both exist on the same system.

  • A client/server connection accommodates connections from remote client machines to databases across a network.

From an application's perspective, the TimesTen API is identical whether it is a direct connection or a client/server connection.

See "TimesTen connection options" for overall information on connection options. See "Database connections" and "Connecting to a database" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for details specific to TimesTen Scaleout.

Load data from an Oracle database into a TimesTen table

You can load the results of a SQL query from a back-end Oracle database into a single table on TimesTen. TimesTen provides tools that execute a user-provided SELECT statement on the Oracle database and load the result set into a table on TimesTen.

TimesTen provides the following methods to accomplish these tasks:

  • Use TimesTen Cache, which provides the connection and transfer of data between an Oracle database and a TimesTen database. You can cache Oracle Database data in a TimesTen database within cache groups. A cache group in a TimesTen database can cache a single Oracle Database table or a group of related Oracle Database tables.

  • The ttIsql utility, an interactive SQL utility, provides the createandloadfromoraquery command that, once provided the TimesTen table name and the SELECT statement, automatically creates the TimesTen table, executes the SELECT statement on the Oracle database, and loads the result set into the TimesTen table.

  • The ttTableSchemaFromOraQueryGet built-in procedure evaluates the user-provided SELECT statement to generate a CREATE TABLE statement that can be executed to create a table on TimesTen, which would be appropriate to receive the result set from the SELECT statement. The ttLoadFromOracle built-in procedure executes the SELECT statement on the Oracle database and loads the result set into the TimesTen table.

System monitoring

You can use system tables, system views, and the ttStats utility for system monitoring and reporting for both TimesTen Classic and TimesTen Scaleout. The following sections describe system monitoring and reporting tools:

System monitoring through system tables and views

TimesTen stores metadata (information about the contents of your database) in system tables in your database. TimesTen also provides system views that allow you to use SQL to query information.

Use the ttIsql alltables to display a list of all system and user tables. Use the ttIsql allviews command to display a list of all system and user views. See "ttIsql" in the Oracle TimesTen In-Memory Database Reference for more information on the ttIsql utility.

See "System Tables and Views" in the Oracle TimesTen In-Memory Database System Tables and Views Reference for full details.

System monitoring for TimesTen Classic

Users have the following options for system monitoring and reporting.

  • You can use the ttStats utility to monitor and display database performance metrics. It generates HTML reports from performance snapshots at user-specified intervals.

    Note:

    System statistics are collected and stored in the SYS.SYSTEMSTATS table; the information is used by various TimesTen utilities and monitoring facilities.
  • You can use the Oracle Enterprise Manager System Monitoring Plug-In for TimesTen In-Memory Database that provides a graphical user interface to monitor database metrics and performance. You can also view reports on the collected metric information, which is useful in diagnosing and troubleshooting database performance issues.

  • You can use the ttStatsConfig, ttSQLCmdCacheInfo, and ttSQLExecutionTimeHistogram built-in procedures to measure and display execution time statistics for SQL operations to determine the performance of SQL statements.

System monitoring for TimesTen Scaleout

Users have the following options for system monitoring and reporting for your grid and database:

Note:

See "Monitoring TimesTen Scaleout" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for full details on system monitoring for TimesTen Scaleout.
  • You can use the ttStats utility enables you to monitor database metrics (statistics, states, and other information) or take and compare snapshots of metrics. It generates HTML reports from performance snapshots at user-specified intervals. For more information, see "Using the ttStats utility" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

    Note:

    System statistics are collected and stored in the SYS.SYSTEMSTATS table; the information is used by various TimesTen utilities and monitoring facilities.
  • You can collect various logs from every host that is part of your grid. These logs are useful for troubleshooting errors that you may encounter while using your grid or database. See "Collecting grid logs" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

  • You can monitor the management instances. See "Monitoring the management instances" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

  • You can use SQL Developer to create, manage, and explore a grid and its components. Additionally, you can also browse, create, edit and drop particular database objects; run SQL statements and scripts; manipulate and export data; view and create reports; and view database metrics. For more information, see "Using SQL Developer to work with TimesTen Scaleout" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

Administration and utilities

Utility programs are explicitly invoked by users, scripts, or applications to perform services such as interactive SQL, bulk copy, backup and restore, database migration and system monitoring.

TimesTen supports typical database utilities such as the following:

  • Interactive SQL (ttIsql).

  • Migrate (ttMigrate) provides a way to quickly move data between different major versions of TimesTen.

  • Many administrative activities are available through SQL statements and system views. TimesTen also uses SQL statements to set up materialized views.

TimesTen Scaleout provides database management through the ttGridAdmin utility.

TimesTen Classic also supports typical database utilities such as the following:

  • Backup and restore (ttBackup and ttRestore).

  • Copy data between different database systems.

  • Using SQL statements to set up replication and caching from an Oracle database.

TimesTen built-in procedures and C language functions enable programmatic control over TimesTen operations and settings. TimesTen command-line utilities enable users to monitor the status of connections, locks, replication, and so on. Status can also be obtained using SQL SELECT queries on the system tables in the TimesTen schema.

See Chapter 9, "TimesTen Administration" for more information on TimesTen administration.

TimesTen Scaleout specific features

In addition to the TimesTen general features, the following features are supported within TimesTen Scaleout

High availability features for TimesTen Scaleout

The TimesTen Scaleout architecture provides high performance and supports high availability.

TimesTen Scaleout enables you to create a grid of interconnected instances running on one or more hosts. You can create a database hosted in the grid and the data stored in that database is distributed across the instances of the grid. Each instance contains one piece (an element) of every database hosted in the grid.

Figure 1-2 highlights this portion of the architecture.

  • TimesTen Scaleout provides high availability by enabling you to specify that the system maintain more than one copy of every item of data within a database, known as K-safety. The number of copies of data is referred to as the k-factor. Your choice to maintain more than one copy protects you from data loss in the event of a single failure. So a grid with k=1 does not provide high availability (as there is only one copy of the data); however, a grid with k > 1 provides high availability.

    Each copy of the database is logically contained within a data space, which logically groups the instances that contain one entire copy of a database. There are always as many data spaces as the grid k-factor.

  • TimesTen Scaleout spreads the work for the database across data instances in parallel, which computes the results of your SQL statements faster. the data in your database is distributed into elements.

  • Your application can connect to any data instance in the grid and transparently access all of the data in the database without having to know where specific data is located.

  • A replica set is a set of database elements with identical contents (the multiple copies resulting from the specified k-factor). Each replica set always contains k elements. The separate elements within a replica set are located across separate data spaces. If one element fails, your connection can be rerouted to the other element in the replica set, if it is still available.

  • You can add or remove instances from your grid to:

    • Expand or shrink the storage capacity of your database as necessary.

    • Expand or shrink the computing resources of your database to meet the performance requirements of your applications.

Figure 1-2 shows a database within the grid where the k-factor is set to 2.

Figure 1-2 Performance and high availability architecture within TimesTen Scaleout

Description of Figure 1-2 follows
Description of ''Figure 1-2 Performance and high availability architecture within TimesTen Scaleout''

For more details, see "Architectural overview of TimesTen Scaleout" in this guide and "TimesTen Scaleout architecture" in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

Transparent data distribution

While TimesTen Scaleout distributes your data across multiple instances, applications do not need to know how data is distributed. When an application connects to any instance in the grid, it has access to all of the data of the database without having to know the location of specific data.

Knowledge about the distribution of data is never required in TimesTen Scaleout, but it can be used to tune the performance of your application. You can use this knowledge to exploit locality where possible.

See "Data transparency" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more details.

Online elastic scalability

TimesTen Scaleout enables you to add or remove instances in order to control both performance and the storage capacity of your database. Adding instances improves the throughput of your workload by providing the additional computing resources of the hosts running those instances. If your business needs change, then removing instances (and their hosts) enables you to meet your targets with fewer resources.

See "Scalability" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more details.

Automatic high availability through K-Safety

As described in "TimesTen Scaleout specific features", TimesTen Scaleout provides high availability and fault tolerance when you have multiple copies of data located across separate hosts with K-safety (k). When one copy of the data is unavailable due to a software error, SQL statements are automatically redirected to the other copy of the data (if possible). In the meantime, TimesTen Scaleout synchronizes the data on the failed system with the rest of the database.

See "High availability and fault tolerance" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more details.

Single point for administration and monitoring

You do not need to log onto every host within a grid in order to perform management activities. Instead, you conduct all management activity from a single management instance using the ttGridAdmin utility. The ttGridAdmin utility is the main utility you use to define, deploy, and check on the status of each database.

You can also use the ttGridRollout utility or the Oracle SQL Developer GUI (both of which use the ttGridAdmin utility under the covers to execute all requests) to facilitate creating, deploying, and managing your grid.

See "Centralized management" in the Oracle TimesTen In-Memory Database Scaleout User's Guide for more details.

TimesTen Classic specific features

In addition to the TimesTen general features, the following features are supported within TimesTen Classic.

High availability features for TimesTen Classic

TimesTen Classic has several features that provide performance and high availability. Figure 1-3 highlights a few of these features.

  • TimesTen Classic replication enables you to achieve near-continuous availability or workload distribution by sending updates between two or more hosts. An active standby pair replication scheme includes an active database, a standby database, and optional read-only subscriber databases. In Figure 1-3, the active and standby databases can be located at a primary site, while a read-only subscriber is located at a disaster recovery site.

  • TimesTen Cache enables you to cache portions of an Oracle database in a TimesTen database in tables within a cache group. In Figure 1-3, tables cached on the Oracle database can be cached as read-only copies in TimesTen. TimesTen Cache automatically propagates changes from the Oracle tables to the cached copy in the TimesTen database.

    In Figure 1-3, there are two Oracle databases set up within an Active Data Guard (ADG) configuration: one at the primary site and the other at the disaster recovery site. ADG propagates any data changes made on the primary Oracle database to the standby Oracle database. When used in conjunction with TimesTen Cache, the integration of ADG within TimesTen ensures that only changes that have been propagated to the standby Oracle database are refreshed to the cache. In the event of a failure of the primary Oracle database, we switch over to the standby Oracle database. After which, the TimesTen Cache also switches over and continues with automatic refresh while remaining consistent with the Oracle database.

    There are other recovery methods for if the standby Oracle database fails or if the entire primary site fails. See "Recovery after failure when using asynchronous Active Data Guard" in the Oracle TimesTen Application-Tier Database Cache User's Guide for more details.

Figure 1-3 Performance and high availability configuration for TimesTen Classic

Description of Figure 1-3 follows
Description of ''Figure 1-3 Performance and high availability configuration for TimesTen Classic''

See "Cached data" and "Replication" for more details on TimesTen Cache and replication.

Data replication between servers

TimesTen Classic provides replication schemes that enable data replication between servers for high availability and load sharing. Data replication configurations can be active-standby or active-active, using asynchronous or synchronous transmission, with conflict detection and resolution and automatic resynchronization after a failed server is restored. See "Data Replication within TimesTen Classic" for more details.

Transaction Log API (XLA)

TimesTen Classic provides an API that enables applications to monitor update activities in order to generate actions outside the database. This capability is provided by the Transaction Log API (XLA), which enables applications to monitor update records as they are committed and take various actions based on the detected updates. For example, an XLA application can apply the detected updates to another database, which could be TimesTen or a disk-based RDBMS. Another type of XLA application can notify subscribers that an update of interest has taken place. This API is supported for C, Java (JMS/XLA) and C++ (TTClasses).

TimesTen Classic provides materialized views that can be used with XLA to enable notification of events described by SQL queries. The primary purpose of XLA is to be a high performance, asynchronous alternative to triggers.

For more information, see "Detect transaction modifications with the Transaction Log API" and Oracle TimesTen In-Memory Database C Developer's Guide.

Automatic data aging

Data aging is an operation to remove data that is no longer needed. There are two general types of data aging: removing old data based on some time value or removing data that has been least recently used (LRU). For example, you can remove yesterday's price list, remove profiles and preferences of users who have logged out from the system, or remove detailed records that are more than 2 days old.

Two types of automatic data aging capability for TimesTen database tables and TimesTen Cache data are available:

  • Time-based data aging based on timestamp values

  • Usage-based data aging based on the LRU algorithm

For more information, see "Implementing aging in your tables" in Oracle TimesTen In-Memory Database Operations Guide and "Implementing aging in a cache group" in Oracle TimesTen Application-Tier Database Cache User's Guide.

TimesTen Cache specific features

The TimesTen Application-Tier Database Cache (TimesTen Cache) provides all of the same features as TimesTen Classic as well as creating an updatable cache for the Oracle database data. It offloads computing cycles from Oracle databases and enables responsive and scalable applications. TimesTen Cache loads a subset of the Oracle database tables into a TimesTen database. It can be configured to propagate updates in both directions and to automate passthrough of SQL requests for uncached data. It automatically resynchronizes data after failures.

TimesTen Cache provides multiple types of cache groups that cache Oracle database tables with automatic data synchronization.

See Chapter 7, "TimesTen Cache" for more details.