Knowledgebase

Memory Files

Memory files are data and index files that are purely memory-resident files that do not exist on disk.

The memory in which memory file data records and index nodes are stored is allocated using the server’s internal memory allocation routines and is separate from the server’s data and index caches. The server uses its memory-management subsystem to allocate and free memory associated with memory files. If the request for memory is at or below 2K bytes, the server uses its own memory sub sub-manager; otherwise, it calls the system memory-allocation routine. When a record or node is deleted, the memory is returned.

In This Section Properties of Memory Files When to Use Memory Files Creating Memory Files

Properties of Memory Files

Because memory files exist purely in server memory (the data never goes to disk), an abnormal server termination or final close of the file destroys the memory file and its existing memory records.

Memory files can be created as PREIMG files or non-transaction files. PREIMG memory files support atomic operations just as disk-based PREIMG files do.

The maximum size of a memory file is limited by the file size specified when creating the memory file. When selecting memory file sizes, take into account the amount of available physical memory on the system. Creating memory files whose size exceeds the amount of available physical memory on the system will cause the operating system to swap memory to disk, which degrades performance.

A memory-resident file cannot be mirrored, partitioned or segmented.

A memory file cannot be backed up by a dynamic dump.

A memory file on a 32-bit server must use 32-bit file offsets (so it cannot be huge); a memory file on a 64-bit server must use 64-bit file offsets (so it must be huge).

• When creating a memory file on a 64-bit server at the c-treeDB level: It is recommended to explicitly include the HUGEFILE attribute in the create statement. This will ensure consistent operation and avoid triggering a potential 582 error.
• When using memory files on a 64-bit server: If you create any indexes that allow duplicates, be sure to include 8 bytes in the total key length (rather than the typical 4 bytes) for the record offset indicator. This will avoid potentially triggering a 582 error.

When to Use Memory Files

Memory files are appropriate to use for data that does not need to be stored to disk. Examples include temporary data that is useful during server operation but would normally be discarded when the server is shutdown and restarted and data that can be restored from another source in the event of an abnormal server termination.

Creating Memory Files

To create a FairCom DB data or index file as a memory file, create an array of XCREblk (extended create block) structures, one for each data and host index file to be created. For each extended create block structure, include the ctMEMFILE attribute in the x8mode field and set the mxfilzhw and mxfilzlw fields to the maximum file size (mxfilzhw is the high-order word and mxfilzlw is the low-order word). Call an Xtd8 create function such as CreateIFileXtd8(), passing the extended create block array to the function.

An attempt to add a new record that causes the memory file to exceed this limit fails, and returns a MAXZ_ERR (667, attempt to exceed maximum file size).

The final close of a memory file causes the server to delete the file. A final close is a file close that causes the user count of the file to drop to zero. In order to ensure that the contents of a memory file are not lost due to an unintentional close of the file, it is possible to make the data file persist even after the final close by including the ctKEEPOPEN bit in the splval member of the file’s extended create block when creating the file. Then the final close leaves the file open (but without any user attached to the file). It can then be opened again, and the data still exists. The file will be closed when the server terminates, or when a call is made to the FairCom DB API function CloseCtFileByName().