The daily edition.

Fileshare Rollback Recovery: Faster, but Only with the Right Logging Guarantees

Scope: Rocket Enterprise Developer 12.0 for Eclipse on UNIX, Fileshare database integrity and advanced recovery logging.

Fileshare recovery is log-dependent. The recovery utility can restore updates after a system failure only when those updates were written to a recovery log. Recovery logging records data-file updates so that a utility can reapply them; after recovery, files represent the state at failure with outstanding transactions rolled back. Basic logging is enabled by default and supplies rollforward recovery. Advanced logging must be enabled explicitly and supplies both rollforward and rollback recovery, plus compatibility with hot backups and a user exit. Only one logging version can be active at a time. See Recovery Logging.

Advanced rollback recovery is generally the faster route because it attempts to restore files at the point where Fileshare failed. Its critical limitation appears when cached data never reached disk: rollback recovery cannot handle that failure mode unless Fileshare was started with both:

• write through (/lw)
• flush on commit (/fc)

These options can be supplied on the command line or in fs.cfg. They impose a documented performance cost because each operation writes data to both cache and disk. The requirement therefore links recoverability directly to the server’s pre-failure startup configuration; it cannot be added after a cache-loss incident. The full behavior is documented in Advanced Rollback Recovery.

Start advanced rollback recovery with the documented command:

fs /rb dbase.ref

Recovery may also require a data scrape when a file was updating its index at failure. A scrape of a large file can be time-consuming. The fsexitproc.cbl exit can use 78-file-recovery-rbld-strt and the file size in offset-x to skip selected large files, but every skipped file must be recorded and recovered later with rollforward recovery.

Once recovery completes, archive the existing log files. Leaving them in place causes the next Fileshare start to fail with:

FS302-S Unable to continue - A log file already exists.

Transaction design also affects operational cost. Fileshare transactions begin with the first WRITE, REWRITE, or DELETE against a file declared WITH ROLLBACK, and end at COMMIT, ROLLBACK, or timeout. COMMIT and ROLLBACK duration is directly proportional to the number of updates, while updated records remain locked during the transaction. Keeping transactions small reduces lock conflicts and shortens completion processing, as described in Transaction Processing (FileShare).

Takeaway: Advanced rollback recovery is not merely an fs /rb command; cache-loss protection depends on /lw plus /fc before failure, skipped scrapes require later rollforward recovery, and completed recovery must be followed by log archival.