|
|
|
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:
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:
MONITOR_MASK MATCH_FILE_ID
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.
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:
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
|
|
|
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.
