|
|
|
Once you establish transaction processing you can take advantage of automatic recovery. Transaction logging places enough information in the transaction log files to ensure transactions can be undone or redone during automatic recovery.
If the application crashes for some reason (anything from a software problem to power failure of the hardware) while instructions are being processed, the application will detect that a problem has occurred the next time it starts up. The transaction management logic will then automatically reset the database back to the last, most complete state that it can, using the transaction log. Transactions committed before the crash will be redone, while those not yet committed will be undone.
Only those files that were created with a transaction mode of ctTRNLOG will be affected.
Automatic recovery also comes into play if the file system is heavily buffered (which dramatically improves performance). With buffering, updates that have been committed may still be sitting in a file buffer somewhere, not yet written to disk. This can be offset by using the file mode of ctWRITETHRU, but that may slow the system down noticeably. Don’t use ctWRITETHRU with ctTRNLOG files. ctWRITETHRU is not necessary because the database server can detect if these buffered transactions have not yet been written to the disk, and will use the transaction log to complete them.
When keeping memory use to a minimum is important, and when automatic recovery requires more FairCom DB file control blocks, set separate limits on the number of files used during automatic FairCom Server recovery and regular FairCom Server operation. Auto recovery may require more files than regular operation because during recovery, files once opened stay open until the end of recovery, which may not be the case with regular operation.
For the FairCom Server, the configuration keyword RECOVER_FILES takes as its argument the number of files to be used during recovery. If this is less than the number to be used during regular operation, (specified by the FILES keyword), the recovery files is set equal to the regular files, and the keyword has no affect. If the recovery files is greater than the regular files, at the end of automatic recovery the number of files is adjusted downward. This frees the memory used by the additional control blocks, ~900 bytes per each logical data file and index.
For non-server implementations, set the variable ctrcvfil to the number of files to use during recovery. In a ctNOGLOBALS implementation, ctrcvfil can only be accessed prior to initializing FairCom DB if the global structure has already been allocated by registering FairCom DB.
If automatic recovery fails on a FairCom Server because a file is missing or does not match the unique file ID, CTSTATUS.FCS receives a message stating SKIP_MISSING_FILES YES has been added to the FairCom Server configuration file. The automatic recovery continues in this case.
For a single-user TRANPROC application, a message about setting ctskpfil to one, (enabled), is placed in CTSTATUS.FCS. When missing files are skipped, the listing of the skipped files indicates the type of log entry that triggered the skipped files message:
The RCVchk or RCVopn could potentially indicate a serious problem, unless of course the file reported has been intentionally deleted or moved. The RCVren value most likely indicates the old or original file has not been located. Of course, if the listed file is the new file this could present a serious problem.
