You can restore a database in the following units. The database recovery utility provides an option to specify these recovery units. The table below shows the database recovery units.
Table 19-1 Database recovery units
Database recovery unit | Description | Option |
---|---|---|
By the system | Restores all RDAREAs in the system (including master directory RDAREAs), except the user RDAREAs. | -a |
By the backup file | Restores 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 RDAREA | Restores specified RDAREAs. A group of RDAREAs can be restored by specifying their RDAREA names as a regular expression. | -r |
The RDAREAs subject to recovery processing (except for the master directory RDAREA) must be in shutdown and closed status (the pddbls command's execution result must be CLOSE HOLD(CMD) or CLOSE HOLD).
To recover in-memory RDAREAs, the in-memory RDAREAs and in-memory data buffer must be in the following status:
If an in-memory RDAREA that is to be subject to recovery processing is not in the requisite status, use the pdmemdb -k rel command to release it from memory, and then execute the pdrstr command.
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.
The following table shows the relationship between the HiRDB start mode and the RDAREAs that can be recovered:
RDAREA type | HiRDB start mode | |||
---|---|---|---|---|
-i | -r[-t] | -l | dbdestroy | |
Master directory RDAREA | N | Y-S | N | N |
Data directory RDAREA | Y-S | Y-B | N | Y-S |
Data dictionary RDAREA | Y-S | Y-B | N | Y-S |
Data dictionary LOB RDAREA | Y-S | Y-B | N | Y-S |
User RDAREA | Y-S | Y-B | N | Y-S |
User LOB RDAREA | Y-S | Y-B | N | Y-S |
List RDAREA | Y-S | Y-B | N | Y-S |
Registry RDAREA | Y-S | Y-B | N | Y-S |
Registry LOB RDAREA | Y-S | Y-B | N | Y-S |
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.
If the master directory RDAREA is defined on a shared disk that is subject to system switchover, some limitations apply when the pdstart -r command is used to start HiRDB. For details about these limitations, see Notes in Starting HiRDB under Standby system switchover (server mode) operation in the HiRDB Version 9 System Operation Guide.
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.
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.
If an RDAREA resulting in an error is to be restored to its most recent status, only that RDAREA is subject to recovery processing. To restore an RDAREA to another status (to the point where its backup was made or to any synchronization point), not only the RDAREA resulting in the error but its related RDAREAs must be restored together.
Suppose that an error occurred in a table storage RDAREA, but the index RDAREA is normal. If only the table storage RDAREA is restored to the point where its backup was made, the table data is restored to the backup acquisition point, but the index data remains in the most recent status, resulting in data inconsistencies. Therefore, the table storage RDAREA and the index storage RDAREA must be restored together to the backup acquisition point.
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.
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 9 System Operation Guide.
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 9 System Operation Guide.
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 Version 9 Staticizer Option Description and User's Guide.
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 9 System Operation Guide.
The figure below provides an overview of recovery with a time range specified.
Figure 19-4 Overview of recovery with a time range specified