TimesTen is an in-memory, relational OLTP database management system supporting SQL through Open Database Connectivity (ODBC), Java Database Connectivity (JDBC) and Oracle Call Interface (OCI) APIs. It services very well for real time application because of short response time and high throughput derived from its in-memory characteristics. TimesTen can deployed in following ways: Classic (single node), Cache and Scaleout (distributed).
TimesTen was originally named as SmallBase and developed by HP Labs. Shortly after its first commercial use in 1995, the product was split out as a separate startup company and renamed as TimesTen. In 2005, the company with 90 employees at the time was acquired by Oracle. TimesTen was then integrated with Oracle software as well as services and become part of [Oracle Database Products](https://www.oracle.com/database/).
TimesTen maintains two checkpoint files (ds0 and ds1) on disk to keep track of metadata of in-memory permanent data. It switches two files when a checkpoint is done to ensure there is always at least one completed checkpoint file for backup and recovery purpose. The rate for checkpointing disk writes is configurable by application. It supports fuzzy or non-blocking checkpoints as well as transaction-consistent checkpoints (i.e. blocking checkpoints).
TimesTen supports columnar compression. This feature uses dictionary-based encoding to replace column values with dictionary table identifiers. It maintains separate dictionary for each column.
Concurrency control of TimesTen is achieved through isolation and locking. It supports fully ACID transactions but allow user to loose it for performance by modifying configuration. ### Locking TimesTen provides three level of lock granularity: row-level, table-level and database-level. By default, row-level locking is used to maximize the throughput. ### Deadlock Detection Deadlock detection is supported in TimesTen with a subdaemon process checking every 2 seconds. It reports and eliminates deadlock when the situation occurs. Application should roll back and retry entire transaction when it is denied a lock due to deadlock error.
TimesTen implements actual relational data model instead of just a relational view.
TimesTen supports foreign keys with proper constraints according to relational database model. Each table may have one or more foreign keys to reference columns in other tables. Foreign key feature is performed through range indexes. Specific constraints implemented in TimesTen for foreign key can be read in documentation of [FOREIGN KEY]( https://docs.oracle.com/cd/E11882_01/timesten.112/e21642/state.htm#TTSQL302).
TimesTen originally used T-Tree indexes as default. Later version of TimesTen moved to range indexes (B+Tree) and supports also hash and bitmap indexes if explicitly specified.
TimesTen provides two different levels of transactional isolation: read committed and serializable. Read committed isolation is used by default. Application can use attribute to change isolation level for its connections and different levels are allowed for concurrent connections. ### Read committed isolation Read committed isolation level enables lockless reads (locks still needed during view maintainence) by reading a separate committed copy of data while writes performed on its own uncommited copy (multi-versioning). In this case, write only blocks other writes. If transaction in this level is performed with operations in serializable isolation level, reads are still non-blocking but write operations block both reads and writes in serializable isolation mode. This mode provides better concurrency comparing to serializable isolation but with the consequences of non-repeatable reads. ### Serializable isolation level This level is used with database-level lock. All locks acquired are kept until the transactions commit or abort.
TimesTen provides two different join method for the optimizer: nested loop join and merge join. Merge join is chosen only when join occurs on columns sorted by range indexes.
TimesTen compile a SQL query through four stages: parser, semantic analyzer, optimizer and eventually code generator to produce executable code.
TimesTen implements industry-standard SQL interfaces.
TimesTen has data resides in main memory. It still stores checkpoint files and transaction log files on disk to achieve persistency.
TimesTen allows creating standalone stored procedures as well as provides some [built-in procedures]( https://docs.oracle.com/cd/E11882_01/timesten.112/e21643/proced.htm#TTREF213).
TimesTen Scaleout uses a shared nothing architecture to achieve linear scalability. Management and administration are centralized and operated on management instances while actual tasks are executed on separate data instances.
TimesTen supports both view (a.k.a non-materialized view) and materialized view. The difference between the two leads to different calculation costs. For view, the cost is paid by the connection that queries the view. While for materialized view, the connection which updates the detail tables encounter the costs. ### View A view is logical and contains no data and therefore will not be dropped or altered by calling those commands on detail tables. If those operations are performed on detail tables with a view presented, referencing the view may fail. ### Materialized view Materialized view is read-only and not available with cache tables. There are two types of materialized view according to update mechanisms: synchronous and asynchronous.
C++, Java, PL/SQL, SQL