|
|
|
If FairCom Server terminates abnormally when there are active transactions or there are open updated transaction-controlled files and it is restarted with the option RECOVER_TO_RESTORE_POINT YES in ctsrvr.cfg then, after FairCom Server completes its automatic recovery, it rolls the transaction-controlled data and index files back to the most recent Restore Point.
The following messages in CTSTATUS.FCS indicate that FairCom Server successfully rolled back to a Restore Point:
- User# 00001 Rollback to Restore Point requested
- User# 00001 Recovery is rolling back to Restore Point ...
- User# 00001 20140707_155104
- User# 00001 Scanning transaction logs
- User# 00001 Recovery rolled back to Restore Point ...
- User# 00001 20140707_155104
- User# 00001 Automatic recovery completed
If a request to roll back to the Restore Point fails because no active Restore Point exists, FairCom Server terminates with error NORP_ERR (1015). If an active Restore Points exists, but the transaction log scanning or the transaction undo's fail, the rollback to the Restore Point returns the error, and the server terminates. An example would be the inability to undo a file delete for a ctRSTDEL file.
Monitoring Restore Point Activity
When FairCom Server successfully rolls back to a Restore Point, it writes an entry to its system log file. After starting FairCom Server, an administrative application can read the system log to determine if the server has rolled back to a Restore Point.
The ctalog.c example program demonstrates how to read records from the system log.
