Please see my other blog for Oracle EBusiness Suite Posts - EBMentors

Search This Blog

Note: All the posts are based on practical approach avoiding lengthy theory. All have been tested on some development servers. Please don’t test any post on production servers until you are sure.

Saturday, December 01, 2012

Oracle TimesTen - Intro

TimesTen - What is it? 
 TimesTen is a memory-optimized, relational database management system with persistence and recover ability. Unlike traditional disk-optimized relational databases, all data within a TimesTen database is located in physical memory (RAM), which means no disk I/O is required for any data operation.

TimesTen provides applications with short, consistent response times and very high throughput required by applications with database-intensive workloads.

Where it is used?
As memory is far faster than hard disk, TimesTen is heavily used in applications where service level agreements require very low and predictable response times, such as telecommunication, real-time financial services trading applications, network equipment, and large web applications.  It can be accessed with standard APIs like ODBC, JDBC, OCI, Pro*C/C++ and ODP.NET, and provides the rich functionality of theSQL query language.
You can use it as:
- The primary database for real-time applications. All data needed by the applications resides in the TimesTen database. 
- Data utility for accelerating performance-critical points in an architecture.
-  Data integration point for multiple data sources on top of which new applications
can be built

In-Memory Database Cache
The Oracle Database option In-Memory Database Cache (IMDB Cache) allows you to cache tables from an Oracle database into a TimesTen in-memory database. An application will typically choose to cache frequently-accessed data or performance-sensitive data.  
Cache group
it uses the concept of a cache group, which is a collection of cached tables related to each other by foreign key constraints.   This is an important feature as the unit of caching and aging becomes a set of records related by foreign key constraints. Each cached table maps to either a full table or a subset of a table in the Oracle database.
Cache grid

A cache grid is a collection of TimesTen databases that collectively manage an application's cached data. Each of the in-memory cache databases participating in a cache grid (also known as grid members) contains one or more cache groups. Global cache groups are cache groups that are shared among cache grid members. Cache grid members use peer-to-peer communication to communicate among each other and to manage the coherence of global cache groups. New cache grid members may attach or detach from a cache grid dynamically 

Architecture and Component Overview

Shared Libraries

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.

Memory-resident Database

 The IMDB Cache or TimesTen database resides entirely in main memory at run time.  It is maintained in shared memory segments in the operating system and contains all  user data, indexes, system catalogs, log buffers, lock tables and temp space. Multiple  applications can share one database, and a single application can access multiple  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.

Database Processes

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:
■ Loading the database into memory from a checkpoint file on disk
■ Recovering the database if it needs to be recovered after loading it into memory
■ Performing periodic checkpoints in the background against the active database
■ Detecting and handling deadlocks
■ Performing data aging
■ Writing log records to files

Connection Modes

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 directly by using the TimesTen direct driver, eliminating the need for any inter-process communication of any kind, thus providing extremely fast performance. 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

Administrative programs 
Utility programs are explicitly invoked by users, scripts, or applications to perform  services such as interactive SQL, bulk copy, backup and restore, database migration  and system monitoring.

Checkpoint and Transaction Log Files

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.
TimesTen replication enables you to achieve near-continuous availability or workload distribution by sending updates between two or more hosts. A master host is  configured to send updates and a subscriber host is configured to receive them. A host  can be both a master and a subscriber in a bidirectional replication scheme.
When replication is configured, a replication agent is started for each database. If multiple databases on the same host are configured for replication, each database has a separate replication agent.Only committed transactions are replicated. On the subscriber host.

No comments: