Nonstop Database, HiRDB Version 9 System Operation Guide

[Contents][Index][Back][Next]

20.7 Handling of synchronization point dump file errors

The following table shows the actions to be taken in the event of an error in a synchronization point dump file.

Table 20-14 Actions to be taken in the event of an error in a synchronization point dump file

Condition at the time of an error HiRDB processing HiRDB administrator's action
Write operation There are files in overwrite enabled status Places the erroneous synchronization point dump file in reserved status and resumes processing using one of the files in overwrite-enabled status. Place the erroneous synchronization point dump file in overwrite enabled status with the procedure shown in (1).
There are no files in overwrite enabled status Terminates abnormally the unit containing the erroneous synchronization point dump file.
  • Create a new synchronization point dump file and then restart the unit.
  • After restarting the unit, place the erroneous synchronization point dump file in overwrite enabled status with the procedure shown in (1).
Read operation If HiRDB cannot read the file of the most recent generation, it attempts to read the file of the immediately preceding generation. If HiRDB cannot read that file either, it attempts to read the file immediately preceding that one. In this manner, HiRDB continues attempting to read a valid synchronization point dump file by tracking back through the file generations. However, if all of these attempts are unsuccessful (if the number of guaranteed valid generations is exceeded), it might mean that the system is not recoverable because the system logs needed to recover the system have been overwritten.
[Figure] If dual synchronization point dump files are maintained
If HiRDB cannot read file A, it attempts to read file B. If HiRDB cannot read file B, it attempts to read file A of the immediately preceding generation, and so on.		 Place the erroneous synchronization point dump file in overwrite enabled status with the procedure shown in (1).
Organization of this section
(1) Procedure for placing an erroneous file in overwrite enabled status
(2) Actions to be taken when HiRDB cannot be restarted because the system log file corresponding to a synchronization point dump file has been overwritten
(3) Actions to be taken when HiRDB cannot be restarted due to an insufficient number of synchronization point dump files

(1) Procedure for placing an erroneous file in overwrite enabled status

Procedure
To place an erroneous file in overwrite enabled status:
  1. Use the pdlogls command to determine the synchronization point dump file that has been reserved due to an error:
    pdlogls -d spd -s b001
  2. If the erroneous file is not reserved, use the pdlogcls command to place it in reserved status:
    pdlogcls -d spd -s b001 -g spdfile1
  3. Use the pdlogrm command to delete the reserved synchronization point dump file:
    pdlogrm -d spd -s b001 -f /sysfile/sync01
  4. Use the pdloginit command to re-create the synchronization point dump file that was deleted in step 3:
    pdloginit -d spd -s b001 -f /sysfile/sync01 -n 5000
  5. Use the pdlogopen command to place the synchronization point dump file re-created in 4 in overwrite enabled status:
    pdlogopen -d spd -s b001 -g spdfile1
We recommend that after the command has executed you check whether the execution results are correct. For details on how to check command execution results, see the manual HiRDB Version 9 Command Reference.

(2) Actions to be taken when HiRDB cannot be restarted because the system log file corresponding to a synchronization point dump file has been overwritten

If an error occurs in a synchronization point dump file, HiRDB attempts system recovery using the preceding generation of the synchronization point dump file. If data is written over the system log file corresponding to the synchronization point dump file (the system log file containing the information needed for system recovery), HiRDB cannot be restarted. In such a case, the pdstart dbdestroy command must be used to start HiRDB forcibly.

In such a case, HiRDB does not inherit information that was in effect during the previous HiRDB session. Therefore, the HiRDB administrator must recover the database. To recover the database, the database recovery utility is executed using the backup copy and system log (unload log) as the input information. For details on the database recovery procedure, see 21. Database Recovery Procedures.

Before executing forced startup of HiRDB, see 1.6.2 Notes on forced startup of HiRDB (or a unit).

Note
  • Until the database has been recovered, the database must be kept inaccessible (place its RDAREAs in command shutdown and closed status with the pdhold -c command).
  • When HiRDB is started forcibly, all RDAREAs that were updated during the previous HiRDB session (including system RDAREAs) are destroyed. The destroyed RDAREAs must be recovered by the database recovery utility; otherwise, subsequent HiRDB operations cannot be guaranteed.
  • RDAREAs are recovered from the system log only. See the KFPS01262-I message that was output when the previous pdstart command failed, and use as the input information to the database recovery utility the file group whose name is displayed as the log reading start file group and the subsequent system log.

(3) Actions to be taken when HiRDB cannot be restarted due to an insufficient number of synchronization point dump files

If the number of synchronization point dump files is less than the number of guaranteed valid generations, HiRDB cannot be restarted. In such a case, take one of the following actions and then restart HiRDB:

The length of time HiRDB is shut down can be reduced by specifying the following operands:

[Contents][Back][Next]

[Trademarks]

All Rights Reserved. Copyright (C) 2011, 2015, Hitachi, Ltd.