This facility is designed to enable the databases defined by the administrator to be brought back to a stable, working position, following a power failure. Without this it is not clear whether all transactions have been committed to the database following such events.
Databases which have been shutdown prior to the power outage will not require recovery, so recovery is not attempted on them.
Those databases which were active at the time the computer lost power will be recovered. This recovery will take the form of a database roll-forward of all complete transactions. A complete transaction is deemed to be one which has entered the commit phase of processing. Those transactions which were incomplete will not be recovered at all. The databases will be left in a consistent state following recovery.
It is the database administrator’s responsibility to determine which transactions require re-entry.
This command is restricted to administrative use only and there are no optional parameters.
This command will inspect the “databases-defined” file and determine whether each of the databases defined therein require to be recovered following a power failure.
Any defined database which has a status of “active” will cause a recovery process to begin – all databases which have been stopped will be in a consistent state. The recovery process takes the form of a roll-forward of the database from the Transaction Journal log files defined for that database. The format of the recovery
command is :
jlogdup –V input set=eldest start=CHECKPOINT output set=database
As this command suggests Checkpointing must be configured for this to be effective. A checkpoint is defined as a point in time when all transactions have completed in their entirety – no partial transactional updates are pending. When Checkpointing is used, the database is deemed to be in a “consistent” state at the point at which the checkpoint record appears in the Transaction Journal. This being the case recovery is only required from the last checkpoint in time. No user intervention is required in determining this time. At the completion of the recovery all transactions which were completed in their entirety will be applied to the database and transactions which are incomplete (i.e. no TRANSEND or TRANSABORT entry found in the log files for
this transaction), will be discarded.
For all computer types, the “WARMSTART” utility should be run with the JBASE_DATABASE set to “warmstart”. It is not possible to predict which database is active (all may not be including “default”. As the access to jBASE databases is determined very early on in the life of a process, the “databases_defined” file cannot
be interrogated to find a usable database. The database “warmstart” also must be started. This will not be added to the “databases_defined” and as such is a special case. This ensures that recovery is not attempted for this dummy database. Once the recovery of all required databases has completed, the dummy database entry is deleted. Note: As DB-START is only possible by a system administrator, misuse of the dummy database is prevented.