Advanced Rollback Recovery is available if you have advanced logging enabled.
In most circumstances, Rollback Recovery is a faster process (than rollforward) to recover data files. Rollback Recovery attempts to recover the data files at the point of the Fileshare failure.
However, in situations where a system failure has occurred in which the cache has not been flushed to disk, Rollback Recovery will not work unless extra logging is enabled.
The extra logging involves enabling the write through (/lw) and flush on commit (/fc) options when Fileshare was started, either on the command line, or by setting them in the fs.cfg file. These two options do come at cost to performance though, as data is written to both the cache and to disk for a single operation.
During recovery from a system failure, or if a data file was in the process of updating their index when Fileshare failed, a data scrape may be required, which if the data file is large, can be time consuming.
If a data scrape is required, the default action is to run it, but you can use fsexitproc.cbl to prevent large files from running a data scrape. Use the 78-file-recovery-rbld-strt clause to interrogate the size of the file (offset-x) and make the decision to perform the data scrape or skip to the next file. You must make a note of any files that are skipped, then perform rollforward recovery on those files.
See the Best Practices Advanced Logging section for the best way to set up Fileshare recovery.
To initiate the advanced Rollback Recovery process:
fs /rb dbase.ref
When recovery is complete, you should archive the existing log files; otherwise you receive the following error when Fileshare is next started:
FS302-S Unable to continue - A log file already exists.