An abnormal server termination is a termination of s FairCom DB process that does not involve a clean server shutdown. FairCom DB may terminate abnormally for the following reasons:
A FairCom DB process encounters a fatal exception, causing the system to terminate the server process. In this case the system may produce a core image of the server process at the time of the exception. The FairCom DB status log may contain error messages related to the exception.
An administrator forcibly terminates the FairCom DB process. In this case, the process is abruptly terminated and theFairCom DB status log does not show an indication of a shutdown occurring.
The system on which FairCom DB is running terminates abnormally (due to power loss, operating system exception, or sudden system reboot). In this case, the server process may be abruptly terminated, which case the status log does not show an indication of a shutdown occurring.
FairCom DB detects an unexpected internal server error situation known as a catend or a terr. In these cases, the server status log shows an error message containing details about the internal server error.
It is important to understand the reason for the abnormal server termination so that the appropriate information about the event can be saved and any necessary actions can be taken before restarting FairCom DB. Follow these steps after an abnormal c tree Server termination occurs:
Examine system logs, application logs, and the server status log to determine the nature of the abnormal server termination.
If a fatal exception terminated the server process, save the core file if it exists.
If the server terminated due to a fatal exception or internal FairCom DB error, save a copy of the server’s *.FCS files, the server configuration file, and if time and disk space permit save a copy of all data and index files before restarting FairCom DB. These files can be used to analyze the abnormal server termination.
If the situation that led to the abnormal server termination can be understood by analyzing the server status log or other system logs, correct the problem that caused the server to terminate. For example, if the server terminated due to insufficient disk space which prevented the server from writing to its transaction logs, free up disk space to ensure the server has enough space for the transaction logs (but do not delete active transaction logs before the server performs its automatic recovery).
Determine the status of PREIMG and non-transaction data and index files and restore or recover these files as needed. PREIMG and non-transaction files are not under full transaction control, so in the event of an abnormal server termination, these files may be in an unknown state. Updates that had been written to the server’s cache but not to disk are lost, data files and index files may be out of sync, and PREIMG files may be in an inconsistent transaction state.
To determine if a PREIMG or non-transaction file needs to be restored or recovered, open the file using a standalone (non-client/server) FairCom DB utility. If the file opens successfully, the file is in good shape. If the file open fails with FairCom DB error 14, the file was updated but was not properly closed and its state is unknown, so the file must be restored or recovered. The options for restoring or recovering PREIMG and non-transaction files following an abnormal server termination are the following:
Re-create PREIMG and non-transaction files and reload their data from an external source if available, or
Rebuild the files to ensure the data and index files are in sync (although unwritten updates are still lost), or
Restore old copies of the files from backup.
Note: See the discussion of the WRITETHRU filemode and FairCom DB error 14 for details on the use of WRITETHRU and server configuration keywords to avoid error 14 for PREIMG and non-transaction files in the event of an abnormal server termination. Be aware that although these options provide ways to avoid error 14 in such a situation, it is still possible for WRITETHRU files to contain data/index inconsistencies or for PREIMG files to be in an inconsistent transaction state following an abnormal server termination.
Recover TRNLOG files using the server’s automatic recovery process. After following the above steps, TRNLOG files can be recovered by restarting FairCom DB. The server detects an abnormal server termination and performs automatic recovery of TRNLOG files, restoring the TRNLOG files to a consistent transaction state. Upon successful completion of automatic recovery, the server is fully operational. At this point clients can connect to the server and can resume their work.
For details on what steps to follow in the event of recovery or restore failures (such as automatic recovery failing), see the section titled “Failures During System Recovery”.
