|
|
|
When opening files, FairCom Server assigns a unique file ID. These IDs change as files are opened and closed over time. Keeping track of those changes is important when reconstructing open and close events after a recovery event for transaction controlled files.
This enhancement (off by default) relieves slow file open and close operations when transaction-controlled files have their file IDs reassigned.
When a file ID of a transaction-controlled file is reassigned, c-tree scans the transaction log from the most recent checkpoint forward looking for a log entry that references the file's file name and file ID.
Scanning transaction logs can take significant time, especially when using large transaction logs. This is done while holding a global mutex, which has the effect of pausing other file open or close requests while the transaction log is being scanned. With the introduction of the system file ID feature discussed below, instead of needing to scan the log, a new log entry is now inserted signaling the file ID reassignment, eliminating the need to finish scanning the remainder of the log. This can offer a substantial time saving during the file open and close operation.
Compatibility of Transaction Logs
Enabling this new behavior breaks compatibility of transaction logs with versions of c-tree Server or standalone utilities that do not recognize this new log entry. For this reason, enabling the new behavior requires the following action depending on the operating mode:
c-tree Server:
To enable the new behavior, add the configuration option LOG_FILE_ID_CHANGE YES to ctsrvr.cfg and restart c-tree Server. To disable the new behavior, use LOG_FILE_ID_CHANGE NO. The default is YES.
Standalone Mode:
To enable the new behavior, call ctSETCFG() before initializing c-tree as shown below:
NINT retval;
retval = ctSETCFG(setcfgCONFIG_OPTION, ""LOG_FILE_ID_CHANGE YES"");
After c-tree has been initialized, the setting cannot be changed. A call to ctSETCFG() to change the setting after c-tree has been initialized returns error code 454 (not supported).
Compatibility Notes
1. Transaction Log Compatibility
When the database engine uses the new log entry (even if the log entry is not present in the transaction logs), the logs are marked as incompatible with a database engine that does not support the new log entry. If an incompatible database engine attempts to use incompatible transaction logs, database initialization fails with c-tree error 666 (LFRM_ERR, incompatible log format) and a message is logged to CTSTATUS.FCS indicating the reason for the log incompatibility.
Example log messages for this situation:
- User# 00001 Incompatible log file format: log is using unrecognized options [5: ct_logsup=47a00490x log_defrel=62200090x unknown=20000000x]
- User# 00001 L0000001.FCS
- User# 00001 Make sure old server shutdown cleanly, and remove old logs before re-starting server
- User# 00001 Could not initialize server. Error: 666
- User# 00001 O1 M0 L74 F666 P0x (recur #1) (uerr_cod=666)
2. Limitation on PUTHDR() call with a mode of ctTIMEIDhdr or ctUNIQIDhdr
A call to PUTHDR() with a mode of ctTIMEIDhdr or ctUNIQIDhdr for a transaction-controlled file that has been updated in the current transaction now fails with error TEXS_ERR. We do not allow changing a file's file ID during a transaction that has updated the file because of possible effects on automatic recovery.
