|
|
|
The best practices outlined in this section should be communicated to all technical and development teams working with FairCom DB. It is also suggested this information should be appropriately included with product documentation as part of deployed installations.
|
|
|
The FairCom DB Server engine requires exclusive access to the files under its control. Therefore do not attempt to copy, delete or in any way replace a file being controlled by the FairCom DB Server engine while the Server is running. This can lead to data corruption and Server instability.
|
|
|
Never interrupt the FairCom DB process during automatic recovery. Data and indexes will be left in an unknown state, resulting in probable data loss. This situation may require restoring data from a clean backup to ensure absolute data integrity.
File ID Overflow during Recovery
When a transaction controlled file is opened by the server, it is assigned a unique fileid which is used to reference it in the transaction logs. This number is stored as a 4-byte integer. If large numbers of files are opened and closed repeatedly, available file numbers can be rapidly consumed, causing a "Pending File ID overflow" message to be logged. This message is logged once every 10,000 file opens. The fileid can be reset by shutting down the server cleanly (so no recovery is needed), and removing existing transaction logs (L*.FCS and S000*.FCS).
An FUSE_ERR error (22) during recovery indicates that the FILES setting should be increased to complete recovery. A RECOVER_FILES keyword (NO by default) is also available that controls this specifically.
RECOVER_FILES <number of files | NO>
Note: Recent improvements to only assign the fileid when a file is actually updated, and not just opened and read from, can substantially reduce the file numbers consumed.
|
|
|
FairCom DB server technology requires that it is the only process operating over any data and index files under its control. Third-party backup (and some virus scan) utilities should never touch any files while FairCom DB has the files open. Doing so on the transaction logs or on a transaction controlled file may terminate the server process. When FairCom DB encounters a write error on these types of files it can no longer guarantee integrity or recovery and must terminate to protect the state of the current system.
If a third-party backup is desired, either use the FairCom DB Dynamic Dump backup facility to create a copy of the files and point the third-party backup to the resulting backup file, or shut down FairCom DB. and then perform the backup.
It is also possible to use a disk-level copy as an acceptable backup strategy, provided FairCom DB is put into a quiet state (using either “Quiesce” or File Block) before the hardware-level copy.
FairCom DB V9.2 and later for Windows also includes Windows VSS support (Volume Shadow Service) for enhanced integration with third-party backup tools.
|
|
|
In the event a problem occurs and requires files to be rebuilt, it is possible to rebuild the files using either a stand-alone utility or the FairCom DB Server. To avoid the potential for wrong PAGE_SIZE settings, and creating indexes without the TRNLOG file mode, FairCom recommends performing all rebuilds through the FairCom DB Server.
