TimesTen In-Memory Database
for Extreme Performance

What is TimesTen?

Sam Drake

Since this blog is about the Oracle TimesTen In-Memory
Database, let’s start by explaining what it is. The product documentation contains an introduction, and the Oracle
Technology Network has several overview presentations that get into the
details. But here’s another quick

TimesTen is…

  • A relational database
  • Providing standard APIs
    and interfaces
  • That runs very fast
    through its memory-centric architecture
  • It can be used standalone
  • Or in conjunction with an
    existing Oracle Database
  • To provide extremely fast
    response time and high throughput

Let’s talk about each of those points in more detail.

A relational database

Like Oracle Database or MySQL, TimesTen is a relational
database. It is used to store and
retrieve data from applications. Applications use Structured Query Language (SQL) to access data in
TimesTen databases. Transactions allow
applications to safely implement complex operations in a multi-user
environment, as in any other relational database. TimesTen databases are persistent … data
stored in TimesTen is stored on disk and can be made highly available even in
the event of disk or system failure.

Standard APIs and interfaces

Also like any relational database, TimesTen provides
standard APIs like JDBC (for Java) and ODBC (for “C” / C++). Applications use these APIs to execute SQL
statements against TimesTen databases to store and retrieve data.

The APIs and SQL that TimesTen provides are compatible with
the facilities provided by the Oracle Database. Our SQL dialect is compatible with theirs … with datatypes like
supports the PL/SQL language for writing stored procedures. And TimesTen also supports Oracle-specific
APIs and tools such as OCI and Pro*C .

Memory Centric Architecture

TimesTen was written from the ground up around the idea that
all the data in a TimesTen database resides in RAM – memory. It’s also stored on disk, for persistence …
in case the power goes out, for example. But while most databases use RAM as a cache of recently-used data from
disk, TimesTen stores all data in RAM all the time.

It turns out that this simple change in architecture can
yield some big benefits … letting us simplify algorithms used under the covers
for searching and storing data. That
means that TimesTen can execute SQL with fewer instructions than many
databases, resulting in faster response time.

Standalone Database…

Since TimesTen is a fully featured relational database, it
can be used by itself to store data for applications. Even though it’s called an “in memory
database”, data in TimesTen is also stored on disk. TimesTen also supports replication of data
between TimesTen databases, which can be used to provide fully fault tolerant
solutions for even the most demanding 24/7 applications.

…or used in conjunction with Oracle Database

TimesTen can also be used in conjunction with an Oracle
Database. For example, you might use a TimesTen database residing on your
application server to cache data from your Oracle Database. For example, as users log on to your website
you might cache their customer profile, shopping cart and order history in the
TimesTen database. TimesTen can
automatically work with Oracle Database to move data back and forth as needed.

This gives your users the response time benefits of an
in-memory solution with the ability to store many terabytes of data of Oracle
Database. The best of both worlds!

Extremely fast response time and high throughput

By storing data in memory, and letting data be accessed at
RAM speeds instead of network speeds, TimesTen can provide extremely fast
response time… measured in microseconds (millionths of a second), rather than
seconds or milliseconds (thousandths of a second).

Useful Links

If you’re just learning about TimesTen, this too-short
introduction probably has left you with more questions than you had
before. Check out the resources below for more
details…and future posts here will dive deeper into some of the topics as well.

Join the discussion

Comments ( 6 )
  • SuoNayi Friday, November 16, 2012

    If my java application and TimesTen both run in the same jvm,will my application run out of memory because that TimesTen stores all data in RAM all the time?

  • Sam Drake Friday, November 16, 2012

    TimesTen stores databases in shared memory, not the JVM's heap. So a Java application using TimesTen doesn't need to adjust its memory sizes or account for the size of the TimesTen database.

    Of course, at the hardware level, you DO need to have enough RAM in the computer for both TimesTen and the applications to live together.


  • SuoNayi Saturday, November 17, 2012

    Thanks for your time Sam.

    If no enough RAM at hardware level what will happen?

    In this case TimesTen will cache subset of all data instead of storing all data in RAM and impact on performance?

  • Sam Drake Monday, November 19, 2012

    When you create a TimesTen database you specify how large it will be. If you try to insert more data into the database than it can hold you'll get an error message.

    So if you have a machine with (for example) 32 GBytes of RAM, you would typically create a TimesTen database on it that is slightly smaller ... perhaps 28 or 30 GB ... leaving memory for the OS itself and other applications to use.

    When TimesTen is being used as a cache of data from Oracle, you can configure TimesTen to automatically AGE OUT data that hasn't been used recently, and that aging can be done based on how full the TimesTen database is. So you can tell TimesTen to cache as much recently-used data from Oracle Database as it can, and it will manage that independently.


  • SuoNayi Thursday, November 22, 2012

    Hi Sam, I want to know how many approachs for my application to interact with Timesten database?

    As far as I know, we can directly connect to the database without network overhead that improves performance, does my application only need specify the DSN name as the name of the data manager's DSN ?There's no document to clarify this clearly.

    The other approach is c/s connection and there are 3 commucation protocols, such as plain tcp/ip, IPC and UNIX domain sockets, aren't they?

  • Sam Drake Tuesday, November 27, 2012

    If your application uses JDBC, then it specifies which TimesTen driver to use (client/server or direct) as well as the DSN to connect to.

    If your application uses ODBC, it simply specifies the DSN ... which driver to use will be determined at link time.

    If your application uses OCI, it uses a tnsnames.ora entry just as it would to connect to Oracle Database. The entry in the tnsnames.ora file will specify then DSN, as well as whether to use client/server or direct linking.

    You might take a look at our "Quickstart", containing samples and examples on how to get started:



Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.