c-treeACE V11.0 Update Guide

Automatic Recovery Considerations

As noted previously, Delayed Durability affects automatic recovery. The following outcomes of automatic recovery are possible after a server crash that occurred when the feature was enabled:

Active Restore Points exist and RECOVER_TO_RESTORE_POINT is YES:
All transactions committed before the Restore Point are recovered, and any transactions committed after the Restore Point are undone.
Active Restore Points exist and RECOVER_TO_RESTORE_POINT is NO:
All transactions committed before the Restore Point are recovered, but some transactions committed after the Restore Point may have been recovered and others lost.
Active Restore Points exist and RECOVER_TO_RESTORE_POINT is not in the configuration file:
All transactions committed before the Restore Point are recovered, but some transactions committed after the Restore Point may have been recovered and others lost; then the server terminates with a NORB_ERR. The next server startup will detect that a rollback to the last active Restore Point is pending. Add RECOVER_TO_RESTORE_POINT YES or NO to the configuration to successfully restart the server.

Note: If automatic recovery has completed the first stage of recovery (i.e., all transactions committed before the crash whose log entries made it to disk are recovered), but the server does not complete the second stage of rolling back to the last Active Restore Point; then the next server startup will detect the pending rollback.

Upon successful rollback to the last Restore Point, the Restore Point log entry is modified to include the skip forward location in the log. The skip forward location stored in the Restore Point permits a roll forward operation to skip over transactions that have been undone because of a prior rollback to the Restore Point.

Note: The modification of the Restore Point log entry is the only time c-tree changes an existing log entry. To avoid permanently corrupting the log containing the Restore Point in the unlikely event that the log update operation fails, the log is copied before attempting to modify the Restore Point entry. The copied log has a name in the form:

LNNNNNNN.FCS.YYYYMMDD_HHMMSS

where NNNNNNN is the log number, and the date and time in the name correspond to the system time at which the log was copied. These copied log files are NOT deleted by the server.

Rollback to New Restore Points with ctrdmp

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:

RSTPNT_NO_CHK.YYYYMMDD_HHMMSS.FCS for a Lightweight Restore Point
RSTPNT_CHKPNT.YYYYMMDD_HHMMSS.FCS for a Checkpoint Restore Point

Note that, as with the !ROLLBACK script keyword, the !RP keyword must be the first entry in the script file.