|
|
|
For non-WRITETHRU files, the server stores data and index updates in its internal cache and does not write updates immediately to disk. For TRNLOG files, this is not a concern because committed updates to TRNLOG files are logged to the transaction logs. For non-TRNLOG files, however, in the event of an abnormal server termination the contents of the cache (and hence any unwritten updates to data and index files) will be lost.
In this situation, the server marks non-TRNLOG files as corrupt to indicate that the file was opened, updated, and not properly closed, so its state is unknown. Attempting to open such a file fails with error FCRP_ERR (14, file corrupt at open). Rebuilding the data file and its associated indexes resets the update flag and allows the application to open the file, but all cached updates that had not yet been written to disk are lost.
The WRITETHRU file mode can be applied to FairCom DB data and index files to cause the server to write updates through the server’s cache to the file system cache or to disk, thereby minimizing the potential for loss of cached updates in the event of an abnormal server termination. While ensuring the updates are written to the file system or to disk, WRITETHRU preserves the updates in the server’s cache so that reads can be satisfied from the server’s cache.
A data or index file can be created as a WRITETHRU file (in which case WRITETHRU is a permanent attribute of the file), or it can be opened as a WRITETHRU file (in which case the file is treated as WRITETHRU until it is closed).
|
|
|
For non-transaction WRITETHRU files, all updates are written through the server’s cache to the file system cache. The server flushes file system buffers on each ISAM update operation for WRITETHRU files. (Low-level updates on WRITETHRU files are written through the server’s cache to the file system cache but are not flushed to disk.)
For PREIMG files opened or created with the WRITETHRU attribute, the server behaves as follows:
WRITETHRU minimizes the possibility of lost updates in the event of a catastrophic event because it writes updated cache pages to disk at the time of the update operation. However, WRITETHRU does not provide the guarantee of recoverability that TRNLOG provides. When using WRITETHRU, it is possible for some updates to be lost or for data and index file inconsistencies to exist following a catastrophe.
ctWRITETHRU behavior for transaction-controlled files
For transaction-controlled files, if ctWRITETHRU is specified at create time, the database engine turns off that bit and sets a separate header bit. This means that a call to GETFIL() with a mode of FLMODE (such as those made by ctinfo) will not display ctWRITETHRU as being in effect for the file.
If the file is a ctPREIMG file, the database engine sets a bit in the tflmod file header field to indicate that the file is in ctWRITETHRU mode. This bit is temporary and not written to the header on disk, so this mode is only in effect until the file is closed. Each physical open of the file must specify the ctWRITETHRU file mode option to enable ctWRITETHRU behavior for the ctPREIMG file.
If the file is a ctTRNLOG file, the database engine sets a bit in the flmode3 file header field to indicate that the file is in ctWRITETHRU mode. This is a permanent header field, so this mode is always in effect for the file. A ctTRNLOG ctWRITETHRU file is put into the O/S-level write-through mode, meaning that each write to the file is automatically flushed through the O/S cache to disk. This is the file-level equivalent of the COMPATIBILITY TDATA_WRITETHRU server configuration option, or COMPATIBILITY TINDEX_WRITETHRU for an index file.
NOTE: If a ctTRNLOG file is created without an extended header, flmode3 will not be persisted to disk, so the file's ctWRITETHRU mode will be lost when the file is closed after create.
|
|
|
WRITETHRU is useful for ensuring that updates to data and index files are written to the file system cache (or to disk in the case of ISAM updates) at the time of the update (or commit in the case of PREIMG WRITETHRU files). PREIMG and non-transaction files that do not use WRITETHRU can experience significant data loss due to unwritten cached data in the event of an abnormal server termination.
