Escolar Documentos
Profissional Documentos
Cultura Documentos
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.2.2 Replication
• 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:
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.