Product Documentation


Previous Topic

Next Topic

Safely Copying FairCom DB Controlled Files

Warning: FairCom DB controlled files should only be copied, moved, or deleted when FairCom DB is shut down. Copying, moving, or deleting files while FairCom DB is in operation can lead to unpredictable errors.

The following are important points for FairCom DB administrators to observe:

  • Do not use system copy utilities to copy FairCom DB data and index files or server administration files (*.FCS) while they are in use by FairCom DB. To safely copy files while the server is operational follow the approaches discussed in the “Online Backup Options” of this document.
  • Do not use third-party file scan or backup utilities on FairCom DB data and index files or server administration files (*.FCS) while they are in use by FairCom DB.

Failing to observe the above recommendations could prevent FairCom DB from accessing the files, which could lead to errors returned to client applications or could cause the server to terminate abnormally. Consider setting file permissions on the c tree data and index files and server administrative files to ensure that only FairCom DB can access these files while the server is running.

Administrators should also be aware of the use of file IDs in the header of FairCom DB data and index files. When a file open is attempted, FairCom DB checks to see if either a file with the same name has already been opened, or if a file with the same unique ID has already been opened. In either case, the match means that a physical file open is not required. Instead the open count for the file is incremented. Checking the unique file ID permits different applications and/or client nodes to refer to the same file with different names: maybe different clients have different drive or path mappings.

However, if two different files have the same ID (a 12-byte value comprised of a Server ID, a time stamp, and a transaction log sequence number), problems could arise because the second file would not actually be opened. The ID is constructed so that no two files could have the same ID unless someone copies one file on top of another. See the warning listed below.

When a file without a matching name does match the unique file ID, a message is sent to the system console indicating the names of the two files involved. This message can be suppressed by adding the following entry to FairCom DB configuration file:


Warning: As discussed above, copying a file to a new name is typically the only way the file IDs can match. If this becomes necessary (that is, only copied when the server is stopped -- do NOT copy, move, or delete files controlled by the server while the server is in operation), use the Update File ID utility, ctfileid.

  • ctfileid.c is located in ctree\samples\special\utils and replaces the previous informal and undocumented utilities, updateid.c and newid.c.

Copying Over Transaction-Controlled Files

Copying over transaction-controlled files poses an additional concern. Even if the server is stopped, it may still need to go through recovery on restart. If files were copied over existing files that need to go through recovery then two outcomes are possible:

  1. If the file IDs do NOT match, the server will detect a file ID mismatch during recovery and fail to start, with messages logged to CTSTATUS.FCS detailing the problem.
  2. If the file IDs match, the server will apply changes from the transaction logs to the new version of the file which are not valid, resulting in the silent corruption of the new data/index.

To verify that the server does not need to go through recovery before copying over existing transaction controlled files, check that CTSTATUS.FCS ends with the normal shutdown sequence, and includes the messages "Perform system checkpoint" and "Server shutdown completed." (The system checkpoint occurred when all connections were closed and the server wrote a clean checkpoint at shutdown so it will not need to perform a recovery upon restarting.)

Tue Sep 23 16:58:08 2014

- User# 00015 Server shutdown initiated

Tue Sep 23 16:58:09 2014

- User# 00015 Communications terminated

Tue Sep 23 16:58:09 2014

- User# 00015 Perform system checkpoint

Tue Sep 23 16:58:09 2014

- User# 00015 Server shutdown completed

Tue Sep 23 16:58:09 2014

- User# 00015 Maximum memory used was 1544324594 bytes

Tue Sep 23 16:58:09 2014

- User# 00015 Maximum number of lock hash bins for a file was 16384

Tue Sep 23 16:58:09 2014

- User# 00015 Maximum number of lock hash bins for a user was 16384

Tue Sep 23 16:58:09 2014

- User# 00015 Maximum number of preimg hash bins for a user was 16384

Previous Topic

Next Topic

File Rebuilds

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.

  • The FairCom DB V9 Server includes a new keyword, MAX_K_TO_USE, controlling the amount of memory utilized for file rebuilds. The default is 64 KB. Increasing this value to as large as practical (not starving the operating system for memory) can provide faster rebuilds than using single-user rebuild utilities.
  • The stand-alone utility has traditionally been a faster method to rebuild files; however, it is important to ensure that the index page size is set appropriately (using the PAGE_SIZE switch). The FairCom DB Server defaults to 8192 byte page sizes (64 sectors - 128 bytes/sector), while FairCom DB standalone technology defaults to 2048 bytes (16 sectors). The stand-alone rebuild utility should also be built with FairCom DB Transaction Processing Logic enabled such that files are created with the appropriate TRNLOG file mode.