Nonstop Database, HiRDB Version 9 System Operation Guide

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

20.8.3 Actions to be taken when a HiRDB (unit) cannot be restarted due to an error in both versions of the current file

If an error occurs in both versions of the current status file, HiRDB (unit) cannot be restarted. In this case, use the pdstart dbdestroy command to start HiRDB forcibly.

Note
When HiRDB is started forcibly, it does not inherit information that was in effect during the previous HiRDB session. Therefore, the HiRDB administrator must recover the database. The database is recovered by executing the database recovery utility (pdrstr command) using a backup copy and the system log (unload log) as the input information.

The following is the procedure for starting HiRDB in the event of an error on both versions of the current file:

Procedure
  1. Check for a disk error (physical error check).
    Check if a disk error has occurred at the disk that stores the status file. Check for a physical error (such as physical damage or a power outage) as well as for an OS or disk driver error; also check that the disk is enabled.
    If the check identifies a disk error, correct it. If it is not possible to correct the error, start HiRDB with the remaining normal disks only. Proceed directly to the next step.
    To determine if a physical error has occurred, refer to Table 20-16 Determining if a physical error has occurred at the disk (physical error check).
  2. Check for a status file error (logical error check).
    Execute the pdcat -d sts command for a status file in which no physical error has occurred and check for an error in its contents.
    For a unit status file:
    pdcat -d sts -u UNT1 -f /sysfile/usts1a -v
    For a server status file:
    pdcat -d sts -s b001 -f /sysfile/sstsb1a -v
    The status file is normal if both the following conditions are satisfied:
    [Figure] The record size displayed in the execution results of the pdcat command matches the record size specified when the status file was created.
    [Figure] No error message was output during execution of the pdcat command.
  3. Use the pdstsrm command to delete the erroneous status files.
    For unit status files:
    pdstsrm -u UNT1 -f /sysfile/usts1a
    pdstsrm -u UNT1 -f /sysfile/usts1b
    For server status files:
    pdstsrm -s b001 -f /sysfile/sstsb1a
    pdstsrm -s b001 -f /sysfile/sstsb1b
  4. Use the pdstsinit command to re-create the status files deleted in step 3.
    For unit status files:
    pdstsinit -u UNT1 -f /sysfile/usts1a -l 4096 -c 256
    pdstsinit -u UNT1 -f /sysfile/usts1b -l 4096 -c 256
    For server status files:
    pdstsinit -s b001 -f /sysfile/sstsb1a -l 4096 -c 256
    pdstsinit -s b001 -f /sysfile/sstsb1b -l 4096 -c 256
  5. Use the pdstart dbdestroy command to start HiRDB forcibly.
  6. Use the database recovery utility (pdrstr command) to recover the RDAREAs.
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.
Note
Starting HiRDB forcibly destroys all RDAREAs that were updated during the previous HiRDB session (including system RDAREAs). The destroyed RDAREAs must be recovered by the database recovery utility; if you fail to do this, subsequent HiRDB operations cannot be guaranteed.