The FairCom Server creates special system files to maintain various kinds of information required to recover from problems. The following list details exactly what files are created, along with all required information needed by the System Administrator responsible for working with them. As the Administrator, be sure these files are backed up when appropriate and used for recovery when necessary.
Note: To be compatible with all operating systems, the names for all these files are upper-case characters.
FairCom Server Status Log
When it starts up, and while running, the FairCom Server keeps track of critical information concerning the status of the FairCom Server, e.g., when it started; whether any error conditions have been detected; and whether it shuts down properly. This information is saved in chronological order in a text file, the FairCom Server Status Log, CTSTATUS.FCS. To control the size of CTSTATUS.FCS, or to maintain inactive logs as T*.FCS files, use the CTSTATUS_SIZE keyword. See the keyword description for more detail.
Administrative Information Tables
The FairCom Server creates and uses the file FAIRCOM.FCS to record administrative information concerning users and user groups. This file can be encrypted with the ADMIN_ENCRYPT keyword. See Configuring the FairCom Server for details.
The FairCom Server creates the following files for managing transaction processing:
Transaction Management Files
I0000002.FCS is an empty file generated at startup by any c-tree database engine with transaction support enabled. This file marks ownership of the process directory to avoid colliding with other FairCom DB processes that may generate their own independent transaction log files. The dump restore utility (ctrdmp) is the most common case where this is reported. When one running process detects this file, a TCOL_ERR error (537) is returned indicating this collision.
Note: It is important to safeguard these files, however only the S*.FCS and D0000001.FCS files should remain after a normal server shutdown.
File Name Mapping
FairCom DB maintains a mapping of file names to file numbers. This is transient information and stored in the D0000000.FCS file.
Delete Node Queue
D0000001.FCS maintains a list of emptied index nodes. These are eventually cleaned up by the delete node thread and remain available for reuse if needed via this queue.
Active Transaction Logs
Information concerning ongoing transactions is saved on a continual basis in a transaction log file. A chronological series of transaction log files is maintained during the operation of the FairCom Server. Transaction log files containing the actual transaction information are saved as standard files. They are given names in sequential order, starting with L0000001.FCS (which can be thought of as “active FairCom Server log, number 0000001”) and counting up sequentially (i.e., the next log file is L0000002.FCS, etc.).
The FairCom Server saves up to four active logs at a given time. When there are already four active log files and another is created, the lowest numbered active log is either deleted or saved as an inactive transaction log file, depending on how the FairCom Server is configured (see inactive transaction logs).
Every new session begins with the FairCom Server checking the most recent transaction logs (i.e., the most recent 4 logs, which are always saved as “active” transaction logs) to see if any transactions need to be undone or redone. If so, these logs are used to perform an automatic recovery. When configuring the FairCom Server, the odd and even numbered logs can be written to different physical devices. See Configuring the FairCom Server.
S00000000.FCS and S0000001.FCS are generated during transaction log checkpoints. These files are used to "kick start" recovery and point to known good transaction states.
Inactive Transaction Logs
Transaction log files no longer active (i.e., they are not among the 4 most recent log files) are deleted by default. To save inactive transaction log files when new active log files are created, add the KEEP_LOGS configuration option to the server configuration with a positive number indicating the number of logs to keep. In this case, an inactive log file is created from an active log file by renaming the old file, keeping the log number (e.g., L0000001) and changing the file’s extension from “.FCS” to “.FCA.” The Administrator may then safely move, delete, or copy the inactive, archived transaction log file.
Temporary Stream Files
The server creates five stream files at startup. These files prevent errors when the operating system has used a large number of file handles and the server needs a stream file. The file names begin with FREOPEN followed by a distinguishing character and ending with .FCS. These temporary files are used for internal server operations and should automatically be deleted during a normal server shutdown.
Optional Server System Event Log
The FairCom Server maintains two optional system files: SYSLOGDT.FCS and SYSLOGIX.FCS. SYSLOGDT.FCS is a FairCom DB data file with a record for each recordable system event. Unlike the CTSTATUS.FCS file, the system log files can be encrypted so entries cannot be added, deleted, or modified with a simple text editor, and vendors can add application-specific entries to the log. See Configuring the FairCom Server or your vendor’s documentation for information on the SYSLOG keywords appropriate to your application.
In case of a system failure, be sure to save all the system files (i.e., the files ending with “.FCS”). CTSTATUS.FCS may contain important information about the failure. When there is a system catastrophe, such as a power outage, there are two basic possibilities for recovery:
Learn more at FairCom Server Status Monitoring Utility, ctsysm.
Deferred Index State File
The DFRKSTATEDT.FCS file stores a list of deferred index states. Learn more at Deferred Indexing in the FairCom DB C and C++ Programmer's Guide.
The SEQUENCEEDT.FCS file stores global sequences. Learn more in these topics:
Replication State File
Once the c-tree Replication Agent has started and successfully connected to both the source and target servers, it will create a set of files on the target server which contains information about the current state and position of replication within the source transaction logs. This allows the Replication Agent to pick up from a previous session should a network connection fail, or the agent is paused for administrative purposes.
For more information, see the Replication Agent Guide.
SQL Swap Files
The LTS* files are from large SQL queries. They are created when sorting of a query grows beyond a set memory bound, causing the sort containers to be moved to disk. They are temporary and should be automatically removed after query execution is completed. An unexpected query could potentially generate these files.
For information about SQL swap files (LTS_* files), see SETENV TPE_TMPDIR.