RECOVER_DETAILS
RECOVER_DETAILS <YES | NO>This keyword enables logging of detailed information about the FairCom DB automatic recovery process. The time spent for each phase of automatic recovery in addition to the number of transactions processed for each phase is provided. This keyword adds minimal overhead to FairCom Server operations.
Below is an example of messages that can be found in CTSTATUS.FCS when LOGIDX is not used during automatic recovery. The description in square brackets indicates why LOGIDX was not used:
Mon Nov 23 09:32:44 2009
- User# 00001 Index repair time: 0 seconds.
Mon Nov 23 09:32:49 2009
- User# 00001 tranrcv: Reconstructing index mark.idx [LOGIDX not in file header]
Mon Nov 23 09:32:51 2009
- User# 00001 tranrcv: Reconstructing index mark.idx M#01 [LOGIDX not in file header]
Mon Nov 23 09:32:52 2009
- User# 00001 tranrcv: Reconstructing index mark.idx M#02 [LOGIDX not in file header]
Mon Nov 23 09:32:53 2009
- User# 00001 Index composition time: 9 seconds.Below is an example of messages found in CTSTATUS.FCS when LOGIDX is used during automatic recovery:
Mon Nov 23 10:46:26 2009
- User# 00001 Index repair time: 0 second(s) for 1 repair(s).
Mon Nov 23 10:46:26 2009
- User# 00001 tranrcv: Recomposing index file FAIRCOM.FCS DI:
Mon Nov 23 10:46:26 2009
- User# 00001 tranrcv: Processing abort node list entries.
Mon Nov 23 10:46:26 2009
- User# 00001 tranrcv: Recomposing index file mark.idx:
Mon Nov 23 10:46:26 2009
- User# 00001 tranrcv: Processing LOGIDX node entries.
Mon Nov 23 10:46:26 2009
- User# 00001 tranrcv: Checking index delete stack.
Mon Nov 23 10:46:26 2009
- User# 00001 tranrcv: Recomposing index file mark.idx M#01:
Mon Nov 23 10:46:26 2009
- User# 00001 tranrcv: Processing LOGIDX node entries.
Mon Nov 23 10:46:26 2009
- User# 00001 tranrcv: Recomposing index file mark.idx M#02:
Mon Nov 23 10:46:26 2009
- User# 00001 tranrcv: Processing LOGIDX node entries.
Mon Nov 23 10:46:26 2009
- User# 00001 Index composition time: 0 second(s).
Default: YES
RECOVER_FILES
RECOVER_FILES <number of files | NO>RECOVER_FILES makes it possible to set separate limits on the number of files used during automatic recovery and regular operations. The reason automatic recovery may require more files than regular operations is that during recovery files opened stay open until the end of recovery. RECOVER_FILES takes as its argument the number of files to be used during recovery. If this is less than the number used during regular operation specified by the FILES keyword, the number of recovery files is set equal to the regular files and the keyword has no affect. If the number of recovery files is greater than the number of operational files, the number of files is adjusted downward at the end of automatic recovery freeing memory used by the additional control blocks, about 900 bytes per logical file.
Default: NO
RECOVER_MEMLOG
RECOVER_MEMLOG <# of logs to load | NO>Loads one or more transaction logs into memory during automatic recovery to speed the recovery process. The argument for this keyword specifies the maximum number of memory logs loaded into memory during automatic recovery.
Default: NO
RECOVER_TO_RESTORE_POINT
RECOVER_TO_RESTORE_POINT <YES | NO>YES causes automatic recovery to recover to the last Restore Point.
When RECOVER_TO_RESTORE_POINT is YES, then automatic recovery (after a crash) comprises two steps:
- the recovery of all transactions committed before the crash; and
- the rollback of transactions to the last Active Restore Point.
If DELAYED_DURABILITY is in effect at the time of the crash, then in step 1 it is not guaranteed that all transactions committed after the last Restore Point have their transaction log entries on disk (i.e., permanent storage).
Note If DELAYED_DURABILITY is in effect and RECOVER_TO_RESTORE_POINT is NO, then automatic recovery will attempt to recover all transactions that had committed before the crash; but some transactions committed after the Restore Point and before the crash may be recovered and others lost so that the files may be in an unexpected state. There is no way to predict which transactions may have been lost.
See Also
RECOVER_SKIPCLEAN
RECOVER_SKIPCLEAN <YES | NO>This keyword may improve recovery times under certain circumstances. Files which appear to have been properly closed are not updated during recovery.
Note For non-server systems, set the NINT global variable ctskpclnfil to 1 to enable this feature.
REDIRECT
The Redirect feature is a useful feature allowing a file originating in one directory structure to be repositioned into another directory location during dynamic dump restore. This support has been extended to FairCom DB autorecovery.
One or more of the following configuration entries are used to specify redirection rules in the server configuration file ctsrvr.cfg:
REDIRECT <old path> <new path>REDIRECT redirects filename references in the transaction logs during automatic recovery to the specified new filename. This option is useful when c-tree data and index files are moved to a different location (on the same system or on another system) before running automatic recovery.
To specify an empty string for one of the !REDIRECT arguments use a pair of double quotes ("").
Examples
If a file originally existed with the name and path C:\Documents and Settings\Administrator\c-tree Data\customer.dat and now exists as the file D:\Documents and Settings\Guest\customer.dat, the following option will allow automatic recovery to proceed and find the file in its new location:
REDIRECT "C:\Documents and Settings\Administrator\c-tree Data" "D:\Documents and Settings\Guest"Here's a similar example using Unix paths, where the original file is named /users/administrator/c-tree data/customer.dat and the file now exists as /users/guest/customer.dat:
REDIRECT "/users/administrator/c-tree data" "/users/guest"Note Use double quotes when a filename contains spaces.
See Also
REDIRECT_IFIL
REDIRECT_IFIL <filename> As a result of redirection during automatic recovery, if the IFIL resource of the file contained a path, this path would be incorrect after the file was redirected to the new location. To support copying c-tree files from one directory location to another (on the same system or on a different system) and accessing them in their new location, it is necessary to update any filename paths in a c-tree data file's IFIL resource.
The FairCom DB configuration option REDIRECT_IFIL <filename> provides support for automatically modifying redirected files on the server. When this option is specified, on server start up (after automatic recovery completes) the file named <filename> is opened and its list of file names is read from it. <filename> is a text file containing one c-tree data file per line. For each file specified in <filename>, FairCom DB opens the file and uses the filename redirection rules (specified with one or more of the REDIRECT options) to change the data and index file paths in the IFIL resource of the file.
Refer to the FairCom DB ctredirect standalone utility to manually modify files that may have been moved.
See Also
SKIP_INACCESSIBLE_FILES
SKIP_INACCESSIBLE_FILES YESForces automatic recovery to skip any file that is not accessible.
See Also
SKIP_MISSING_FILES
SKIP_MISSING_FILES <YES | NO>This keyword is available for special FairCom Server startup conditions. If a user file required by the FairCom DB Server during automatic recovery was deleted, an error 12 might be returned and the FairCom Server would not continue. By adding SKIP_MISSING_FILES to the default ctsrvr.cfg file, the error will be logged and the FairCom Server will successfully start up.
SKIP_MISSING_FILES is not recommended as a permanent setting. Deleting files under transaction processing control adversely affects database integrity.
Default: NO
See Also
TRANIDX_LOPN_ERR_CONTINUE
TRANIDX_LOPN_ERR_CONTINUEIn unusual situations, index reconstruction during automatic recovery could fail with error LOPN_ERR (96) due to a missing transaction log (e.g., L*.FCS). Starting with FairCom DB V11.5, it is possible to use the configuration option TRANIDX_LOPN_ERR_CONTINUE to allow automatic recovery to continue by adding this keyword to ctsrvr.cfg and restarting the FairCom DB Server process.
If recovery then completes successfully, the only issues caused by the missing transaction log was an inability for the FairCom DB Server to properly update an index node on disk.
In this case, the data files under transaction logging control (e.g., with file mode ctTRNLOG) are fully intact, and only the indexes need to be rebuilt to ensure the data and index files are fully in sync. Note, this is expected to be an unusual situation and FairCom recommends using extreme caution with this keyword. FairCom does not recommend enabling this keyword by default. It should only be enabled when required to recover from a catastrophic situation.
To use this option, add TRANIDX_LOPN_ERR_CONTINUE to ctsrvr.cfg. When this option forces the automatic recovery to continue, the following message is logged to CTSTATUS.FCS:
WARNING tranidx could not open previous log file: 96
Upon completion of automatic recovery in this situation, the following message is logged to CTSTATUS.FCS, and FairCom DB Server terminates with error 571 to indicate to the administrator that all indexes should be rebuilt:
Note tranidx continued without required logs. Recovery completed but index rebuild is required.
Automatic recovery terminated with error: 571
If the automatic recovery does NOT complete successfully after adding this keyword, then the missing transaction log is preventing FairCom DB from being able to successfully recover from the catastrophic situation and a backup should be used to restore the data to a known state.