- \n
- Invented at HP Labs in 1994<\/li>\n
- Embedded into HP\u2019s Open Call solution<\/li>\n
- Spun off in 1996 as VC funded startup<\/li>\n
- Thousands of production customers<\/li>\n
- Acquired by Oracle Corporation in 2005<\/li>\n
- 3 major releases since 2005: 6.0, 7.0, 11gR2,18c Release 1<\/li>\n<\/ul>\n
<\/p>\n
Overview of Oracle TimesTen <\/strong><\/p>\n
Oracle TimesTen In-Memory Database is an in-memory, relational database management system with persistence and high availability. 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.<\/p>\n
TimesTen databases have high persistence and availability. It provides for very low latency and high throughput, being an in-memory database. Other features include standard relational database APIs like JDBC and ODBC. TimesTen can not only be used as a standalone in-memory database but also provides the utility of being used as a cache in other relational databases, including the Oracle Database itself. It is often used in extremely high-volume OLTP applications including financial trading and telecom billing.<\/p>\n
How TimesTen Stores Data on Disk<\/strong><\/p>\n
![\"times](\"\/wp-content\/uploads\/2026\/blog_article_images\/26387-body-Picture1_12.png\")
<\/p>\nImage Source<\/a> <\/p>\n
Each TimesTen data store has exactly two checkpoint files. A checkpoint is called every 10 minutes by default; this writes the dirty memory pages to the first checkpoint file, and then the next checkpoint uses the other checkpoint file. Write transactions are placed in an in-memory buffer first, then flushed to the log files.<\/p>\n
Two Types of Transactional Logging:<\/strong><\/p>\n
Buffered Logging: <\/strong><\/p>\n
(SPEED: FAST, DURABILITY: GOOD<\/em>) Transactions are saved to an in-memory log buffer first. When the buffer fills, it is flushed to disk in the background. The process is very fast (5000 TPS or more). There is a small chance that transactions could be lost if a crash occurs before the buffer is flushed. The customer can configure the size of the log buffer.<\/p>\n
Durable Commit<\/strong><\/p>\n
(<\/strong>SPEED: SLOW, DURABILITY: EXCELLENT<\/em>) <\/strong>Every transaction is flushed to disk immediately. The speed of this depends on the speed of the disk device. Since every transaction is saved to disk, this is very durable.<\/p>\n
The customer may switch from BUFFERED LOGGING to DURABLE COMMIT at any time by calling a SQL function called ttDurableCommit().<\/em> The customer can flexibly control the durability vs. performance at run-time, something that is not possible with a conventional RDBMS.<\/p>\n
Significant Response Time Improvement: In-Memory Database Cache + Oracle Database<\/strong><\/p>\n
![\"times](\"\/wp-content\/uploads\/2026\/blog_article_images\/26387-body-Picture2_15.png\")
<\/p>\nImage Source<\/a><\/p>\n
The above graph shows the average transaction response time measured for each of the 7 transaction types. <\/p>\n
The red bars are the response time obtained when the data is cached in the TimesTen IMDB. It\u2019s a huge improvement for the application database operation. Remember a good part of the response time on the Oracle database is due to the client-server connection and the network roundtrip, neither exists when the application links directly to the TimesTen database in memory. Applications can also connect to TimesTen via TCP\/IP client\/server.<\/p>\n
Creating a TimesTen Database<\/strong><\/p>\n
Define a DSN<\/strong><\/p>\n
\u2022 <\/strong> DataStore attribute: Specifies the directory name of the database\u2019s checkpoint files <\/p>\n
ex: DataStore=\/data\/TTDEMO\/TTDEMO-DSN1\/TTDEMO-DSN1<\/em><\/strong><\/p>\n
\u2022 <\/em><\/strong> LogDir attribute: Specifies the directory name for transaction log files. The transaction log contains log records for each database update, commit, and rollback.<\/p>\n
\u2022 DatabaseCharacterSet attribute: Character set in which data is stored Logically divided into two separate memory regions<\/p>\n
Database Memory Regions<\/strong><\/p>\n
- \n
- Permanent region <\/li>\n
- PermSize DSN attribute configures its allocated size.<\/li>\n
- Region stores persistent database elements (ex: tables, indexes)<\/li>\n
- The region is written to disk during a checkpoint operation.<\/li>\n
- Temporary region <\/li>\n
- TempSize DSN attribute configures its allocated size<\/li>\n
- Region stores transient data and information generated when executing statements (temp tables, stored result sets…)<\/li>\n
- The database will be automatically created when the instance administrator connects to the database<\/li>\n<\/ul>\n
$ttisql <DSN name><\/em><\/p>\n
\u2022 Ttisql utility connects to server DSN directly and ttIsqlCS utility connects to TimesTen client DSNs. <\/p>\n
$ttisql connStr “DSN=TTDEMO-DSN1;UID=timesten;pwd=timesten”<\/em><\/p>\n
\u2022 RAM Policy: Determines when the database is loaded into and unloaded from memory.<\/p>\n
- \n
- inUse: The database is in memory if it is in use (default policy). <\/li>\n
- always: The database is always kept resident in memory. <\/li>\n
- manual: The database is manually loaded into and unloaded from memory.<\/li>\n<\/ul>\n
GitOps can enable an effective foundation for building Cloud Native applications.The key principles of GitOps highlight the following benefits for organizations:<\/p>\n
In-Memory Database Cache<\/strong><\/p>\n
![\"times](\"\/wp-content\/uploads\/2026\/blog_article_images\/26387-body-Picture3_10.png\")
<\/p>\n
![\"times](\"\/wp-content\/uploads\/2026\/blog_article_images\/26387-body-Picture4_9.png\")
<\/p>\n