When HiRDB (or a unit) is started forcibly, the information that was in effect during the previous session is not inherited. Therefore, HiRDB cannot restore the database to its status during the previous session. Instead, the HiRDB administrator must restore the database's status.

When HiRDB is started forcibly, all RDAREAs (including system RDAREAs) that were updated during the previous session are corrupted.

The corrupted RDAREAs must be recovered with the database recovery utility before forced startup. HiRDB operations cannot be guaranteed unless the RDAREAs are recovered.

Procedure

The following is the procedure for recovering corrupted RDAREAs:

1. Check the KFPS01262-I message that was output when HiRDB restart failed.
2. Check in the KFPS01262-I message the group name of the system log's input starting file and check the system log that is created thereafter.^#
3. Recover the RDAREAs using the system log checked in step 2 as the input to the database recovery utility (pdrstr command). RDAREAs can be recovered only from the system log.

#: The pdlogls -d sys command is used to check the system log.

pdlogls -d sys Group Type Server Gen No. Status Run ID Block No. logfg01 sys sds 1 cnu---u 35108db8 1 2 logfg02 sys sds 4 cn---cu 3510ecba 10 0 logfg03 sys sds 1 cn----- 3510ecba 1 3 logfg04 sys sds 2 cn----- 3510ecba 4 8 logfg05 sys sds 3 cn----- 3510ecba 9 f logfg06 sys sds 0 cn----- 00000000 0 0

Explanation

If logfg04 and 5 are displayed in the KFPS01262-I message as the fg name and block number, respectively, it is clear from Run ID, Gen No., and Block No. that the system log files were used in the following order:

logfg04 logfg05 logfg02

This means that the system log file to be used has the same Run ID as the file group displayed in the KFPS01262-I message and a generation number greater than displayed under Gen No..

This method is not applicable when the server in a HiRDB parallel server configuration is started and terminated individually at each server.