|
|
|
Disk I/O operations are expensive in terms of performance, causing a bottleneck when permanently storing data. Because database file management is an intensely I/O-bound process, any advantage that can be obtained by keeping data in memory will provide faster response times to applications.
To cope with the hindrance of disk I/O, techniques have been devised to allow a program to continue executing without waiting for data to be written to disk. These techniques typically involve writing the data to a cache buffer (in fast temporary memory) where it will be stored until it can be flushed (written to disk) at a later time. As soon as the program has written data to the cache, it can go on processing the next instructions. The cache will be flushed to disk during idle time between other operations. If the cache is independent of the CPU (such as cache built into the disk controller), it may be possible to flush the cache while the application and operating system are busy.
|
|
|
The FairCom DB Server maintains data and index caches in which it stores the most recently used data images and index nodes. These caches provide high-speed memory access to this information, reducing demand for slower disk I/O. The server writes data and index updates first to cache and eventually to disk. Data and index reads are satisfied from the server’s cache if possible. When necessary, the server writes parts of the cache to disk. The server also supports background flushing of cache buffers during system idle times.
The cache sizes are determined by the server configuration file. It is possible to disable caching of specific data files and to dedicate a portion of the data cache to specified data files.
|
|
|
Although the caching technique described above can be an efficient method for storing data to disk with minimal impact on performance, it has implications regarding data recovery. The program's logic may assume the data is safely stored on disk (permanent storage) when, in fact, it is still in the cache memory (temporary storage) waiting to be written to disk. If the system encounters a catastrophic failure, such as a power failure, before the cache can be flushed, the program may not be able to recover that data.
FairCom DB provides its own caching that is integrated with the program's logic. When data is written to disk, it is stored in a temporary cache that will be flushed to disk during idle time. Although the program can continue with certain operations while the data is still in the cache, it does not consider the write to be completed until the cache buffer is flushed to disk. If the file is under transaction control, system recovery can use the transaction log to restore the data in case of a failure.
|
|
|
A typical server provides several "layers" of caching, which can be thought of as a "cache stack." Each layer of your cache stack has a different impact on performance and data integrity. The diagram below depicts the layers of caching that may be present on your system:
|
|
Application Level Caching - FairCom DB provides its own caching integrated into the product so that flushing of the cache can be coordinated with recovery logs. |
|
|
File System Caching - The operating system typically provides caching. This cache can benefit performance but it places non-transaction controlled data at risk. It is vulnerable in the case of a hardware failure or power loss. |
|
|
Hardware Caching (level 1) - Some disk controllers include their own hardware caching. In case of failure, there is no guarantee that recovery will be possible. |
HDD Caching |
|
Hardware Caching (level 2) - Most modern hard disk drives have caching built in. |
HDD Platter |
|
Physical Medium - This is where the data is written to permanent storage. |
A virtual machine will add at least one layer of caching.
The layers of caching provided by the file system and the disk controller do little to improve performance beyond FairCom's built-in caching. In some cases (e.g., with very large data sets), the file system cache is simply added overhead that may slow down the performance gains provided by FairCom DB caching. It is recommended that file system cache be shut off for critical data files (use the UNBUFFERED_IO keyword on Windows).
Caching provided by the disk controller is completely transparent to applications and the operating system. As such, the program is not able to know if the cache has been flushed of if data is waiting to be written to disk. This makes it impossible for the program to recover the data if a failure occurs while it is waiting in the disk controller's cache. For data integrity, disk controller cache should be disabled.
|
|
|
FairCom DB provides its own caching. By integrating this caching with the logic of the core engine, flushing of the cache can be coordinated with transaction logs. Transaction control is turned on when creating the file by setting the file mode or storage attributes. A utility (cttrnmod) can be used to change the modes of existing files.
When a file is under transaction control, nothing is placed into cache until the transaction is committed. (The transaction is held in temporary memory, called PreImage, until it is complete.) Although there is some overhead from transaction control, this cache provides good performance while maintaining data integrity.
Three different levels of transaction processing are provided by FairCom DB: Full, PreImage, and None. Your choice of transaction control affects both performance and recoverability. The next section describes these modes in detail.
