TimesTen

TimesTen functionality is contained in a set of shared libraries that application developers link to their application, allowing TimesTen to execute as part of the application's process. This shared library approach is different than conventional RDBMS systems where the database is essentially a set of distinct processes to which applications connect via some form of inter-process communication. This communication may take the form of a client/server connection spanning over a network or it may be some form of intra-system IPC such as a Unix domain socket connection or a shared memory based connection mechanism.[10]

The data for each active TimesTen database is stored in a shared memory segment, allowing multiple TimesTen databases to be active concurrently, and also allowing an application to simultaneously access several TimesTen databases on the same system. On 64-bit platforms, the size of a TimesTen database is practically limited only by the amount of RAM available on its host computer. One customer has a production TimesTen database approaching two terabytes in size[11] utilized for on-line transaction processing.

Starting TimesTen requires starting a background process called the TimesTen main daemon, which then starts multiple TimesTen subdaemon processes to manage each database created in the system. These subdaemon processes perform database operations such as:

1. loading and unloading the database into RAM
2. writing periodic fuzzy checkpoints of the TimesTen database to disk
3. writing transaction log records from the in-memory log buffer to the transaction log files on disk
4. handling deadlocks

Client applications that connect to traditional disk-based relational databases typically use TCP/IP or another IPC mechanism to communicate with a database server process. In TimesTen, applications that reside in the same server as the TimesTen database can connect directly to the in-memory image of the database by using the TimesTen direct driver, eliminating the need for any inter-process communication of any kind, thus providing extremely fast performance.[12] If the application resides on a remote server, the application can also connect to the TimesTen database using the traditional client/server model of data access.

All TimesTen data exists in RAM, however TimesTen does utilize non-volatile storage (such as a hard disk) for database persistence and recoverability. A TimesTen database stores all transactional data modifications in an in-memory log buffer, which is eventually persisted to disk in the form of transaction log files. In addition, TimesTen also persists snapshots of the in-memory database, called checkpoint files, to disk. The combination of checkpoint files and transaction log files allow TimesTen to provide recoverability in the event of a system failure. TimesTen implements a parallel log manager in order to maximize throughput on large SMP systems.

By default, TimesTen operates in non-durable commit mode. In this mode, a commit operation occurs purely in memory, and the writing of the log records for the transaction to disk occurs asynchronously to the commit.[13] This provides for very low response times and very high throughput at the cost of the potential for some small amount of data loss in the event of a system failure. A true synchronous commit mode (durable commit mode) is also provided; this mode avoids the possibility of any data loss at the cost of reduced performance. When operating in synchronous commit mode, TimesTen provides automatic group commit optimization. TimesTen allows the architect / developer to balance performance versus data safety by providing control of the commit mode at three different levels: database, connection, and transaction. Another option for data protection and high-availability is to use TimesTen replication.[14]

The TimesTen replication mechanism enables a highly available system by sending database updates between two or more hosts. With TimesTen replication, a master host sends updates to one or more subscriber hosts. TimesTen recommends an active-standby pair configuration for highest availability.[15] An active-standby pair consists of two master databases, an active and a standby database. In addition to the active and standby databases, multiple subscriber databases can be configured to serve as disaster recovery copies or read-only farms.

Replication in TimesTen is implemented by the replication agent, a daemon process that aims at every TimesTen database involved in replication. The replication agent sends and receives updates between databases by communicating with the replication agents of other databases involved in the same replication scheme. Change capture is via log-mining with in-memory optimization; under normal operating conditions change records are captured from the in-memory log buffer with no need for any disk I/O. Communication between replication agents is via an efficient stream-oriented protocol built on top of regular TCP/IP connections.[16] The replication agent is multi-threaded and in the 11.2.2 release, TimesTen supports parallel replication for increased throughput. The replication workload is automatically parallelized to maximize throughput while still maintaining correctness.[17]

TimesTen provides the capability to cache data from an Oracle Database source. When used in this fashion, TimesTen is referred to as Oracle In-Memory Database Cache (IMDB Cache), an Oracle Database product option.[18]

To utilize Oracle Database caching, one defines one or more SQL objects known as cache groups. A cache group is a set of one or more related database tables and allows for subsets of its rows and/or columns. Database tables in a cache group must each have a defined primary key or a unique index declared across a set of non-nullable columns and must be related in a parent-child hierarchy via primary key-foreign key constraints. SQL predicates can be used to control what data is to be cached.

Once a cache group is defined, the cache group can then be "loaded", allowing Oracle Database data to be cached in TimesTen. Applications can then read from and write to cache groups, and all data modifications will then be synchronized with the corresponding Oracle database tables either automatically or manually.

TimesTen provides an event notification mechanism through the transaction log API (XLA). XLA provides functions which allow applications to be notified of data changes occurring in TimesTen tables (and also DDL occurring in the TimesTen database). XLA can also be used in conjunction with materialized views to simplify the process of monitoring changes made to rows spanning multiple tables. XLA works by mining the TimesTen transaction log stream in a similar manner to the replication agent. Database application deployments that do not include an Oracle database which want to use TimesTen as an in-memory cache database can use XLA to capture updates and, via custom application code, apply these updates to their backend database.