19.2 Information required for recovering databases

Organization of this section
(1) Database recovery units
(2) Status of RDAREAs subject to recovery processing
(3) Relationship with the backup acquisition mode
(4) Restoring the master directory RDAREAs
(5) Restoring only backup data using the backup file acquired before a configuration change
(6) Restoring to the most recent status
(7) Database restored using the unload log file or system log file
(8) Recovery when operating HiRDB without unloading the system log
(9) Recovery from a backup using the differential backup facility
(10) Recovery from a backup using the inner replica facility
(11) Recovery with range specification
(12) HiRDB status during database recovery utility execution

(1) Database recovery units

You can restore a database in the following units. The database recovery utility provides an option to specify these recovery units. Table 19-1 shows the database recovery units.

Table 19-1 Database recovery units

Database recovery unitDescriptionOption
By the systemRestores all RDAREAs in the system (including master directory RDAREAs), except the user RDAREAs.-a
By the backup fileRestores the RDAREAs in the backup file.-c
By the unit*Restores all RDAREAs in a specified unit.-u
By the server*Restores all RDAREAs in a specified server.-s
By the RDAREARestores specified RDAREAs. A group of RDAREAs can be restored by specifying their RDAREA names as a regular expression.-r
* This is applicable to a HiRDB/Parallel Server only, not applicable to a HiRDB/Single Server.

(2) Status of RDAREAs subject to recovery processing

The RDAREAs subject to recovery processing (except the master directory RDAREA) must be in shutdown and closed status (CLOSE HOLD(CMD) or CLOSE HOLD displayed by the pddbls command).

(3) Relationship with the backup acquisition mode

If the backup file was created by the database copy utility specifying the -M s option, you need not only the backup file but also the unload log file or system log file.

(4) Restoring the master directory RDAREAs

To restore an RDAREA, you need to place the RDAREA in the shutdown and closed status by the pdhold command. However, the master directory RDAREA cannot be placed in the shutdown and closed status. To restore the master directory RDAREA, you need to terminate HiRDB once and then restart it using the pdstart -r command.

Therefore, to restore all RDAREAs including the master directory RDAREA, you must start HiRDB using the pdstart -r command.

(5) Restoring only backup data using the backup file acquired before a configuration change

To restore only backup data using the backup file acquired before the configuration was changed (HiRDB file was added), first delete all the HiRDB files constituting the RDAREA.

(6) Restoring to the most recent status

To restore an RDAREA to the most recent status, you need the backup file and the system log file that is output after the last backup. This means that you need the system log stored in the current system log file. Because the current system log file cannot be unloaded, use the pdlogswap command to swap the log files, then unload the file containing the current system log information.

(7) Database restored using the unload log file or system log file

If you have restored a database using an unload log file or a system log file, be sure to back up the restored RDAREA immediately after recovery processing. If you do not and an error occurs, the database recovery utility cannot restore the database to the synchronization point immediately before the error.

To restore a database using unload log files, you must specify all required unload log files. If any required unload log files are missing, the utility displays a message (KFPR16203-E or KFPR16301-E) and terminates with an error.

(8) Recovery when operating HiRDB without unloading the system log

If you are operating HiRDB without unloading system log information, then in the event of a database error you can recover the database using the system log information as the input information for the database recovery utility, without having to unload the system log information. This mode of operation is called operation without unloading the system log.

Operation without unloading the system log is based on the log point concept. To recover a database from an error, you do not need the system log information from before the point when the last backup was made. The location that distinguishes the system log information required for recovery of the database from the unneeded system log information is called a log point. A log point is set when the database copy utility is used to make a backup copy.

To recover the database during operation without unloading the system log, specify the -L and -z options.

For details about operation without unloading the system log, see the HiRDB Version 8 System Operation Guide.

(9) Recovery from a backup using the differential backup facility

To recover the database from its backup obtained using the differential backup facility, specify the -g and -K options.

For details about the differential backup facility, see the HiRDB Version 8 System Operation Guide.

(10) Recovery from a backup using the inner replica facility

To recover the database from its backup obtained using the inner replica facility, specify the -q and -x options.

For details about the inner replica facility, see the HiRDB Staticizer Option Version 7 Description and User's Guide.

(11) Recovery with range specification

When restoring a database using an unload log file or system log file, you can specify a range of recovery time. This time range can also be specified for each RDAREA to be recovered. When a time range is specified, only those logs output by transactions with synchronization points that fall within the specified time range are recovered. Following is an example of logs subject to recovery when the database is restored with a time range specified. For details about recovery with a time range specification, see the HiRDB Version 8 System Operation Guide.

Figure 19-4 shows an overview of recovery with a time range specified.

Figure 19-4 Overview of recovery with a time range specified

[Figure]

Explanation
If a transaction is executing at the start point, such as Transaction 1 in the figure, the utility recovers it using the log collected since the start point.
The utility does not recover a transaction, such as Transaction 3, that has not reached a synchronization point by the recovery end time. The utility recovers a transaction that has reached a synchronization point within the specified time range, using the log up to the synchronization point. For a transaction, such as Transaction 3, that has not reached a synchronization point, the utility issues a warning message to that effect.

(12) HiRDB status during database recovery utility execution

  1. You can execute the database recovery utility only when HiRDB is active.
  2. Execute the database recovery utility at the server machine containing the single server or the server machine where the system manager is located.
  3. To execute the database recovery utility, the unit containing the RDAREAs subject to recovery processing must be active, as well as the unit containing the unload log file, system log file, or backup file used for recovery processing. If only a backup file is used to restore RDAREAs, the server containing the RDAREAs to be restored may not be active; however, if an unload log file or system log file is to be used, the server must be active.