The profound improvements in computer architectures over the last decade gave rise to In-Memory Database technology. CPU performance (as measured by circuit density) has been doubling, on average, every year and a half Memory chips have doubled in capacity at half the cost in the same intervals. Today, a gigabyte of physical memory for a server costs around $100. Once prohibitive, the cost of RAM is no longer a factor in the consideration of production-scale In-Memory Databases for front-office applications. Back-office systems and data warehouses are still largely the domain of disk-based databases, which may store hundreds of gigabytes of historical data that’s rarely accessed. Magnetic disk performance has increased much more slowly. Thus, the performance gap between CPUs and disks has widened substantially. Data integrity and functional richness are the other major advantages of an IMDB product. Real-time applications impose fixed deadline on completion of transactions .Applications such as router have to handle a huge amount of traffic data, in short period of time. Other application areas where there is immense need of high performance are mobile communication and telecommunications systems. Such applications expect very short and predictable access and response times from the underlying storage system. Conventional DBMS incurs a lot of disk interaction, and cannot ensure predictable response times, hence proving itself unsuitable for these kind of applications. For predictable and short response time, data has to be kept in main memory.

As a result, the storage system for most of these applications is custom-designed, and lack to ensure durability and consistency of the data.Further, due to impedance mismatch (difference in schema definitions), data can hardly be shared across application boundaries. This motivates the need of some system that allows access to shared in-memory data, ensuring ACID properties on it. One approach towards this problem is to modify the DBMS to incorporate huge in-memory buffer.But, storage and indexing architecture of such a system is designed for disk. Disk block is the unit of data access. For every access/up date of and at a item, the system calculates its physical address. The target block is searched in buffer pool.Now,if the buffer pool size is big enough to accommodate the whole database, linear search will be inefficient.If buffer pool is not big enough, page fault will occur, resulting into disk access for the block, increasing the response time.

Either way, this approach is not suitable. This motivates the need to develop a DBMS, whose storage and indexing components are designed for in-memory data. Such a DBMS is Main Memory DBMS (MMDB).In a Main Memory Database (MMDB) system, the primary copy of the database resides in volatile main memory as opposed to Disk Resident Database (DRDB) systems where the database is on disk. The perception of where the data resides is important here. With an MMDB the DBMS software is designed assuming that the data is memory resident. With a DRDB the DMBS software is designed assuming the data is stored on disk and I/O is required to access the data. MMDB systems need not perform I/O operations for database applications. Thus, they are ideal for applications that require high Throughput and a fast response time. With the increasing demand for high-performance systems and the steady decrease in memory cost, MMDBs have become an attractive alternative to DRDB’s.

This is especially the case for telephone switching applications, mobile computing applications and real-time systems, i.e. applications that require high throughput and fast response time. The increasing popularity of MMDBs can be illustrated by the sizable effort of research done in this area .The end result of In-Memory Database technology is a significant reduction in the amount of CPU needed to complete standard database operations – as Database technology is a significant compared to a fully-cached RDBMS. The actual difference depends on exactly what work is being done. Read operations (e.g. reference data lookups) exhibit the greatest speedup Write operations, which probably entail some logging of changes to disk to guarantee recoverability, could be slowed down somewhat by database operations. The disk operation. In practice, applications are almost never only reads or only.