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.
In V11 and later, ctrdmp is able to rollback to a Restore Point. Restore Points permit server clients to establish quiet spots in the transaction log where there are no active transactions.
Prior to the V11 modifications, ctrdmp could either perform a dynamic dump recovery or rollback to a specified date and time. ctrdmp has been extended such that, as an alternative to specifying a date and time, the rollback script can provide the name of a Restore Point file.
A typical ctrdmp script file used for a rollback looks like:
!ROLLBACK
!DATE MM/DD/YYYY
!TIME HH:MM:SS
....
Now the script can be composed as follows:
!RP <Restore Point File Name>
....
The Restore Point File Name generated by the server is either of the following:
Note that, as with the !ROLLBACK script keyword, the !RP keyword must be the first entry in the script file.
See also