TimesTen is an in-memory, relational database management system with persistence and recoverability.

Originally designed and implemented at Hewlett-Packard labs in Palo Alto, California, TimesTen spun out
into a separate startup in 1996 and was acquired by Oracle Corporation in 2005.[1]
All data within a TimesTen database is located in physical memory (RAM), which means that no data
operation requires disk I/O. This is unlike traditional disk-optimized relational databases such as the Oracle
Database, DB2, Informix or SQL Server, whose designs must contain algorithms that attempt to minimize
disk accesses.[2] TimesTen provides applications with short, consistent response-times and very high
throughput as required by applications with database-intensive workloads. [3]
As memory operates far faster than hard disk, TimesTen is used in applications where service-level
agreements require low and predictable response times, such as telecommunications, real-time financial-
services trading applications, network equipment, and large web applications. Also, unlike other memory-
caching systems that use key-value pairs (such as Memcached, Hazelcast or Coherence), TimesTen can
be accessed with standard interfaces and provides the functionality of the SQL query language.

Applications with data residing in an Oracle Database can utilize TimesTen through a database caching
option (as distinct from Oracle Database In-Memory[4][5]), in which TimesTen functions as an in-memory
cache database in front of an Oracle Database.[6]
TimesTen runs on most major Unix/Linux platforms and on various Windows platforms, in both 32-bit and
64-bit modes.[7]

Contents

[hide]

• 1 Technology

• 1.1 Architecture

• 1.1.1 Shared libraries

• 1.1.2 Memory-resident database

• 1.1.3 Database processes

• 1.1.4 Connection modes

• 1.2 Availability and integrity

• 1.2.1 Checkpoint and transaction log files

• 1.2.2 Replication

• 1.3 In-memory database cache

• 1.4 Event notification

• 2 History
• 3 References

• 4 External links

Technology[edit]
TimesTen is an in-memory database management technology that provides very fast data access time. It
assumes all data will reside in physical memory (RAM) during run time. [8] The result is very low response
times, which enable high throughput, even on commodity hardware. [9]

Architecture[edit]
Shared libraries[edit]
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]
Memory-resident database[edit]
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.
Database processes[edit]
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
Connection modes[edit]
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.
Availability and integrity[edit]
Checkpoint and transaction log files[edit]
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]
Replication[edit]
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 activeand 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.