The duration of the restart essentially depends on the duration of the physical repair and the logical resetting of the open transactions. The aim is to reduce the duration of the restart to a minimum. The following sections explain the options provided to you for this purpose by the DBH.
Reducing the duration of physical repair
In physical repair, the afterimage blocks are written from the TA-LOG files to the databases.
The more often the afterimage blocks are saved during normal operation, the fewer data blocks have to be written in the event of a restart. This reduces the time required before normal operation can be resumed after an interruption. You can increase the frequency with which the afterimage blocks are written during the session by means of the BUFFER-LIMIT and TALOG-LIMIT parameters of the DBH option RESTART-CONTROL (see "RESTART-CONTROL").
However, too much saving during normal operation can affect performance. You should therefore use the performance monitor to keep track of the I/O rates and make changes, if necessary, to the BUFFER-LIMIT and TALOG-LIMIT parameters during operation using the MODIFY-RESTART-CONTROL administration statement (see "MODIFY-RESTART-CONTROL").
Delaying logical resetting in normal operation
In a logical reset, the transactions that were open at the last consistency point are reset on the basis of the logical beforeimages.
When LOGICAL-ROLLBACK = *DELAYED is set with the DBH option RESTART-CONTROL (see "RESTART-CONTROL"), this reset can be delayed until normal operation begins after a restart. The reset operations then run parallel to the normal transactions and requests of users and are synchronized accordingly as in normal operation.
Delaying of the logical reset is suppressed in the following cases, even if the option described in the previous paragraph is used:
In the event of a restart because of a bottleneck affecting the transaction log files, since the removal of the bottleneck is not to be expected before the open transactions are reset.
In the event of a restart because of a bottleneck affecting a DA log file. In this situation, it is only possible to read the databases. The open transactions therefore have to be reset here as well before a restart.
In the event of a restart because of a defective catalog space. In this case, too, the transactions have to be reset immediately, since the repaired data and index spaces are physically closed at the end of the restart on account of the missing catalog space.