SESAM/SQL carries out a restart when operations are resumed after errors have occurred.
During a restart, the DBH rolls back the transactions that were still active at the time the error occurred to the last valid consistency point. This returns all the databases involved to a consistent state. For the restart to succeed, the DBH has to have been logging transactions and the transaction log files TA-LOG1, TA-LOG2 and WA-LOG must be available for the time of the crash. If one of these files is not available or if the files were written at different times, no restart is possible. Depending on whether the current DBH session is interrupted or not, the DBH carries out an external or internal restart.
External restart:
The DBH carries out this type of restart after a system failure if it is loaded after an abort session. If the system fails, transaction logging allows the SESAM/SQL DBH to restart automatically. The databases are treated as follows:The status of the last consistency point is recovered on the basis of the physical before image blocks. Any database write jobs that had not been executed at this point are now implemented on the basis of the after images (physical repair)
Following this, all transactions that were active at the time of the last consistency point are rolled back on the basis of the logical before image (logical repair).
After the restart, the databases remain open and can once again be used by application programs.
Internal restart:
Restart after a minor internal error. The DBH carries out an internal restart without interrupting system operation.
In the case of an internal restart, physical and logical repair is performed once the internal memory areas have been reinitialized. The session then continues.
The time taken by the restart depends primarily on the period required for physical and logical repair. The following control options are available to reduce the time up to renewed DBH availability after the restart:
You can influence the frequency with which the after image blocks are written to the database during normal database operation.
You can delay logical reset until normal operation recommences after a restart.
The more frequently modified blocks are written to the database during normal operation, the less often this operation has to be performed during physical repair on the basis of the after images following a restart. This reduces the time required before normal operation can be resumed after an interruption. However, excessively frequent database writes during normal operation can have a negative impact on performance. You should therefore monitor the I/O rates during normal operation and adapt the settings during normal operation if necessary (see the “Database Operation” manual).
If you delay the logical reset until the start of normal operation then the reset operations are performed in parallel with the normal user transactions or jobs and are synchronized as in normal operation. For a detailed description of this operation, refer to the “Database Operation” manual.