Introduction

---

DBISAM uses caching and buffering algorithms internally to ensure that data is cached for as long as possible and is accessible in the fastest possible manner when needed to perform an operation. The following information details these internal processes.

Buffer Replacement Policy

---

Any buffer maintained within DBISAM is replaced using a LRU, or least-recently-used, algorithm. For example, if the cache is full when reading a record, DBISAM will discard the least-recently-used record buffer in order to make room for the new record buffer. The "age" of a given buffer is determined by the access patterns at the time. Every time a buffer is accessed it is moved so it is the first buffer in the list of available buffers. This would make it the "youngest" buffer present in the list of available buffers, and all other buffers would be moved down the list. As a particular buffer moves down the list it becomes "older" and will be more likely to be removed and discarded from the list of available buffers.

Read Ahead Buffering

---

DBISAM performs intelligent read-ahead when reading records and BLOB blocks. For read-ahead on records, this intelligence is gathered from information in the active index for a given table and allows DBISAM to determine how records physically align with one another on disk. Performing read-ahead in this manner can reduce the number of I/O calls that DBISAM has to make to the operating system and can significantly speed up sequential read operations such as those found in SQL queries and other bulk operations.

Block Writes

---

When DBISAM writes data to disk it aligns the data according to its physical placement on disk and attempts to write all of the needed data in the fewest number of I/O calls that is possible. This reduces the number of I/O calls and can make commit operations for transactions extremely quick, especially for bulk appends of records within a transaction.

OS Buffering

---

In addition to the buffering provided by DBISAM, additional buffering may be provided by the operating system in use. When DBISAM writes data using operating system calls, there is no guarantee that the data will be immediately written to disk. On the contrary, it may be several seconds or minutes until the operating system lazily flushes the data to disk. This has implications in terms of data corruption if the workstation is improperly shut down after updates have taken place in DBISAM. You can get around this by using the TDBISAMSession ForceBufferFlush property or by using the TDBISAMTable or TDBISAMQuery FlushBuffers method. The most desirable way to ensure that data is flushed to disk at the operating system level is the FlushBuffers method since the ForceBufferFlush property is very disk-intensive and may cause write performance to drop below an acceptable level. The FlushBuffers method, on the other hand, can be used in critical places in an application to ensure that data is flushed to disk in a timely fashion without necessarily sacrificing performance.

Modifying the Amount of Buffering

---

DBISAM enables you to modify the amount of memory used for buffering each table's record, index, and BLOB field data. Please see the Customizing the Engine topic for more information.