|
|
|
The following configuration file entries are used to configure Restore Points:
KEEP_RESTORE_POINTS |
<N> (defaults to 1) |
Number of active Restore Points to maintain |
RECOVER_TO_RESTORE_POINT |
YES/NO (defaults to YES) |
YES causes automatic recovery to recover to the last Restore Point |
KEEP_RESTORE_POINTS <N> allows the server to maintain information about the last N Restore Points. This is somewhat like the KEEP_LOGS keyword. The last N Restore Points are referred to as the "Active Restore Points." It is possible to set N to zero which means there will be no Active Restore Points. If there are no Active Restore Points, then automatic recovery cannot rollback to a quiet transaction state. The list of Active Restore Points is stored in each checkpoint. In the case of a Checkpoint Restore Point, the checkpoint includes itself as the last Active Restore Point.
Note: When N is greater than zero, the server automatically maintains the transactions logs necessary to ensure that a rollback to any of the Active Restore Points is possible. However, KEEP_RESTORE_POINTS does not affect the existence of the Restore Point files. These files are quite small (128 bytes), and are not deleted by the server.
When RECOVER_TO_RESTORE_POINT is YES, then automatic recovery (after a crash) comprises two steps:
If Delayed Durability is in effect at the time of the crash, then in step 1 it is not guaranteed that all transactions committed after the last Restore Point have their transaction log entries on disk (i.e., permanent storage).
Note: If Delayed Durability is in effect and RECOVER_TO_RESTORE_POINT is NO, then automatic recovery will attempt to recover all transactions that had committed before the crash; but some transactions committed after the Restore Point and before the crash may be recovered and others lost so that the files may be in an unexpected state. These is no way to predict which transactions may have been lost.
Note: There is a subtle distinction between these configurations:
(a) an explicit RECOVER_TO_RESTORE_POINT NO in the configuration file
(b) no RECOVER_TO_RESTORE_POINT entry in the file (which defaults to a NO)
If a server is running with Delayed Durability enabled when it crashes, then at the next startup in the case of (a) the server will successfully restart with a warning message that not all transactions may have been made good. In the case of (b) the server will fail its restart with an error NORB_ERR (no rollback to Restore Point) or NORP_ERR (no active Restore Points). The reason for this difference is so that the system administrator must explicitly request that recovery from the crash should proceed without a rollback. With Delayed Durability off, cases (a) and (b) will behave the same.
