Product Documentation

Knowledgebase

Previous Topic

Next Topic

Non-Transaction Files

Depending on the application’s requirements, it may be appropriate to create certain data and index files without transaction control. Non-transaction files avoid the overhead associated with transaction processing but do not guarantee atomicity of operations or recoverability of updates.

In This Section

Properties of Non-Transaction Files

Backup and Restore Options for Non-Transaction Files

When to Use Non-Transaction Files

Creating Non-Transaction Files

Previous Topic

Next Topic

Properties of Non-Transaction Files

The state of a non-transaction file at a point in time is stored in a combination of the following locations:

  • Updated server data/index cache pages. (Updates held in server memory: this is volatile storage)
  • Filesystem cache pages. (Updates written to filesystem but not flushed to disk held in system memory: this is volatile storage)
  • Disk file contents. (Updates written to filesystem and flushed to disk: this is non-volatile storage)

The server does not guarantee that unwritten updated data and index cache pages are backed by a persistent copy on disk, so non-transaction files are not recoverable in the event of an abnormal server termination. In such a situation a non-transaction file is in an unknown state because an unknown number of updates may have not yet been written to disk at the time of the abnormal server termination.

Previous Topic

Next Topic

Backup and Restore Options for Non-Transaction Files

Backup copies of non-transaction files can be made using the following approaches:

Online backup using dynamic dump

FairCom DB’s dynamic dump feature can be used to backup non-transaction files. However, unlike PREIMG and TRNLOG files the dynamic dump cannot guarantee a consistent point in time backup for non-transaction files. Non-transaction files are flushed if possible at the beginning of the dynamic dump. If successfully flushed and not updated during the dynamic dump, the file is marked clean in the dynamic dump stream file; otherwise it is marked dirty. At dump restore time, clean files have their update flags cleared but the update flag remains set for dirty files. A dirty restored file could be missing updates and dirty data and index files could be out of sync. Dirty restored files must be rebuilt to clear the update flag and to ensure consistency between data and index files.

Offline backup using file copy

An offline backup of TRNLOG files can be performed using system file copy utilities when the server is shut down or when the server is running and the files to be backed up are closed. It is important to ensure that the server is shut down or the files are closed before making a backup copy of files using a system file copy utility in order to ensure that all updated buffers are flushed to disk. Otherwise, data may be lost and the file may be in an inconsistent state.

Previous Topic

Next Topic

When to Use Non-Transaction Files

Use non-transaction files when the files are of a temporary nature and can be re-created or the data in the files can be restored from another source in the event of an abnormal server termination.

To minimize loss of unwritten cached non-transaction file updates in the event of an abnormal server termination, consider using WRITETHRU for non-transaction files or periodically calling the FairCom DB API function CtreeFlushFile() to flush non-transaction data and index cache pages to disk.

Previous Topic

Next Topic

Creating Non-Transaction Files

To create a non-transaction data or index file, do not include the TRNLOG or PREIMG file modes in the filemode value specified when creating the file.

  • If using an ISAM-level file creation function, do not include TRNLOG or PREIMG in the dfilmod and ifilmod fields of the IFIL structure supplied to the function.
  • If using a low-level file creation function, do not include TRNLOG or PREIMG in the filemode parameter supplied to the function.

TOCIndex