6.8.1 About backup-hold

In the following cases, the target RDAREAs must be backed up and held:

When RDAREAs are backed up and held, the backup can be made even during an online session. Specify the -b option in the pdhold command to back up and hold RDAREAs.

Organization of this subsection
(1) Types of backup-hold
(2) Conditions (RDAREA configuration)
(3) Notes
(4) Relationship to lock
(5) Volume of system log information output during updatable backup-hold
(6) Determining the system logs needed for database restoration

(1) Types of backup-hold

The four types of backup-hold are explained in Table 6-5.

Table 6-5 Types of backup-hold

Backup-hold typeExplanation
Reference-possible backup-holdDuring backup-hold, RDAREAs that have been backed up and held can be referenced; an updating attempt results in an SQL error (-920).
Characteristics and precautions
  • Using the backup made here, the database can be restored to the backup acquisition point.
  • No deadlock with an updating transaction occurs.
  • If a no-log-mode updating transaction is executed for an RDAREA that is in reference-possible backup-hold status, the updating transaction goes into lock-release wait status for the RDAREA, causing an error after lock release. As a result, the RDAREA goes into error shutdown status.
Reference-possible backup-hold (update WAIT mode)During backup-hold, RDAREAs that have been backed up and held can be referenced; an updating attempt goes into lock-release wait status until the backup-hold is released.
Characteristics and precautions
  • Using the backup made here, the database can be restored to the backup acquisition point.
  • Specify in the pd_lck_wait_timeout operand or the PDCWAITTIME operand of the client environment definition a time value that is longer than the backup-hold period. If the updating transaction times out, an SQL error (-770) occurs.
  • Deadlock may occur with an updating transaction. To ensure that the updating transaction does not terminate with an error, specify pd_deadlock_priority_use = Y. If deadlock occurs, all locks in the backup-hold collected by the pdhold command are released, and the same backup-hold processing is attempted again for up to five times. If deadlock results on the fifth retry, all locks in the backup-hold collected by the pdhold command are released, and the pdhold command terminates in an error.
  • If a no-log-mode updating transaction times out or terminates in an error after a deadlock, an updated RDAREA goes into error shutdown status.
Updatable backup-holdDuring backup-hold, RDAREAs that have been backed up and held can be referenced and updated. Even while an updating transaction is being executed, an RDAREA is placed immediately in updatable backup-hold status without placing the pdhold command in wait status.
Characteristics and precautions
  • The database cannot be restored to the backup acquisition point; it can only be restored to a synchronization point after the backup acquisition point. To restore the database, the backup and the system log from a synchronization point immediately prior to backup acquisition are required.
  • If an updating transaction in the pre-update log acquisition mode or the no-log mode is executed between the previous synchronization point and the current time, do not apply updatable backup-hold; the database cannot be restored using this backup.
Updatable backup-hold (WAIT mode)During backup-hold, RDAREAs that have been backed up and held can be referenced and updated. If an updating transaction is being executed, the pdhold command is kept waiting until the transaction terminates.
Characteristics and precautions
  • When the contents of a buffer that was updated by an update transaction occurring during backup-hold are applied to an RDAREA, the KFPH00157-W message is output when backup-hold is released. When this message has been output, the database cannot be restored to the backup acquisition point; it can only be restored to a synchronization point subsequent to the backup acquisition point. Therefore, to restore the database, you must have a system log from the time at which execution of the backup hold command began.
  • If the KFPH00157-W message was not output, you can use the backup made here to recover the database to its status at the time of the backup. However, if the backup was made in the pdcopy command's updatable mode (-M s specified), the database cannot be restored to the backup acquisition point; it can only be restored to a synchronization point after the backup acquisition point. To restore the database, the backup and the system log from the synchronization point immediately prior to backup acquisition are required.
  • An updating transaction in the pre-update log acquisition mode or the no-log mode is placed in lock-release wait status at the RDAREA that has been backed up and held. Therefore, specify in the pd_lck_wait_timeout operand or the PDCWAITTIME operand of the client environment definition a time value that is longer than the backup-hold period. If the updating transaction times out, it terminates in an error.
  • Deadlock may occur between an updating transaction in the pre-update log acquisition mode and an updating transaction in the no-log mode. To ensure that the updating transaction does not terminate in an error, specify pd_deadlock_priority_use=Y. If deadlock occurs, all locks in the backup-hold collected by the pdhold command are released, and the same backup-hold processing is attempted again for up to five times. If deadlock results on the fifth retry, all locks in the backup-hold collected by the pdhold command are released, and the pdhold command terminates in an error.
  • If an updating transaction in the pre-update log acquisition mode or the no-log mode times out or terminates in an error after a deadlock, an updated RDAREA goes into error shutdown status.
Reference note
Reference-possible backup hold and reference-possible backup hold (update WAIT mode) are also referred to as committing a database; they are required when the inner replica facility is used. For details about the inner replica facility, see the manual HiRDB Staticizer Option Version 7 Description and User's Guide.

(2) Conditions (RDAREA configuration)

  1. Place the files comprising the RDAREAs to be backed up on a disk, so that they can all be backed up in a single backup operation.
  2. When creating a HiRDB file system area for RDAREAs in a regular file, specify the -i option in the pdfmkfs command.
  3. To restore the database to the most recent synchronization point after an error has occurred (including restoration with a range specified), the master directory RDAREA and other RDAREAs must be restored separately. Therefore, take one of the following measures so that the master directory RDAREA can be restored separately:
    • Create a partition and logical volume for storing the master directory RDAREA only, thus enabling backup exclusively for the master directory RDAREA.
    • Use the pdcopy command to back up the RDAREAs in the partition containing the master directory RDAREA.

(3) Notes

  1. If HiRDB is terminated abnormally or forcibly while the disk being used by HiRDB is being backed up, that backup becomes invalid. In this case, make the backup again.
  2. If the RDAREA is in updatable backup hold or updatable backup hold (WAIT mode) status, RDAREA automatic extension is suppressed. For this reason, you should refrain from executing a job to add or update a large volume of data that requires allocation of new pages while the RDAREA is in either of these hold statuses. To cancel suppression of RDAREA automatic extension, use the pdrels command to release the RDAREA from the hold.
  3. When you use a function other than the pdcopy command (i.e., a function provided by a different product) to make a backup, do not execute the database structure modification utility (pdmod command) while the backup processing is underway.
  4. If HiRDB is terminated abnormally or forcibly during backup-hold, the backup-hold may not be inherited when HiRDB is restarted, depending on the backup-hold type. In this case, make a backup by implementing the backup-hold again. Table 6-6 shows the backup-hold inheritance status during HiRDB reactivation.

    Table 6-6 Backup-hold inheritance states during HiRDB reactivation

    Backup-hold typeBackup-hold status inheritance during reactivation
    Reference-possible backup-holdYes
    Reference-possible backup-hold (update WAIT mode)No
    Updatable backup-holdNo
    Updatable backup-hold (WAIT mode)No

Yes: Status is inherited.

No: Status is not inherited.

(4) Relationship to lock

(a) Lock-release timeout during backup-hold

Note that a lock-release timeout might occur when the following backup-hold modes are used:

For a reference-possible backup-hold (update WAIT mode), an updating transaction waits for lock release at the RDAREA that has been backed up and held (resource type 0602) until the backup-hold is released. In the updatable backup-hold and updatable backup-hold (WAIT mode) modes, an updating transaction in the no-log mode or pre-update log acquisition mode waits for lock release at the RDAREA that has been backed up and held (resource type 0602) until the backup-hold is released.

Consequently, if the value specified in the pd_lck_wait_timeout operand or the PDCWAITTIME operand of the client environment definition is shorter than the time between backup-hold and its release, the updating transaction terminates in an error. If such an error occurs, change the specification values of these operands.

Backup acquisition in these modes is recommended when the mirror disk facility with a short duration between shutdown and release (the time needed for dividing the logical volume only) is used for making backups.

(b) Deadlock during backup-hold

Note that a deadlock might occur when backup and hold is applied to multiple RDAREAs in the following modes:

In the reference-possible backup-hold (update WAIT mode) mode, deadlock with an updating transaction may occur. In the updatable backup-hold and updatable backup-hold (WAIT mode) modes, deadlock may occur with an updating transaction in the no-log mode or pre-update log acquisition mode. To ensure that the updating transaction does not terminate in an error, specify pd_deadlock_priority_use = Y. In this case, if deadlock occurs, the pdhold command terminates in an error. Therefore, re-execute the pdhold command after a short while. If multiple RDAREAs are specified in the pdhold command, backup-and-hold processing for all RDAREAs becomes invalid. If multiple RDAREAs are backed up and held using the pdhold command multiple times, deadlock may occur in the RDAREAs that have been backed up and held. In this case, first release the RDAREAs that have been backed up and held and then re-execute the pdhold command. Therefore, when applying backup and hold to multiple RDAREAs, specify multiple RDAREAs in a single pdhold command (repeat execution of the command until successful).

In the case of a HiRDB/Parallel Server, global deadlock can occur if RDAREAs on different servers are specified. HiRDB cannot detect global deadlock, so the transactions result in timeout errors. To avoid global deadlock, execute the pdhold command in units of servers when you specify more than one RDAREA.

(5) Volume of system log information output during updatable backup-hold

When the database is updated during updatable backup-hold, the volume of system log information that is output increases by the amount determined by the following formula:

[Figure]

Note
If HiRDB is terminated abnormally or forcibly during backup-hold, the backup-hold is not inherited during HiRDB reactivation (except when reference-possible backup-hold is used). Consequently, the amount of system log information indicated by this formula is not output in this case.

a: Number of RDAREAs updated during updatable backup-hold

Si: RDAREA page size (bytes)

Ti: Number of pages updated in the RDAREAs updated during updatable backup-hold

The number of updated pages in the RDAREAs is determined according to the following procedure.

Procedure
To determine the number of updated pages in the RDAREAs:
  1. Execute the statistics analysis utility (HiRDB file statistical information related to database operations) at the following times:
    [Figure]At the start of updatable backup-hold
    [Figure]At the release of updatable backup-hold
  2. Refer to the number of synchronous WRITEs (SYNC-W) and determine the number of updated pages from the difference.

(6) Determining the system logs needed for database restoration

To restore the database to the most recent synchronization point (including restoration with a range specified), the system logs after the backup acquisition are needed. Table 6-7 shows how to determine the system logs needed for database restoration.

Table 6-7 Determining the system logs needed for database restoration (when backup-hold is being used)

ConditionDetermining the system logs needed for database restoration
  • Referencing-possible backup-hold
  • Referencing-possible backup-hold (update WAIT mode)
The system log subsequent to when the backup was made is needed. Before making a backup, execute the pdlogls command to record the following information about the current system log:
  • System log service run ID (Run ID)
  • System log file generation number (Gen No.)
  • System log file's file group name (Group)
Also record the date and time of backup. Specify this time if the -T option is to be specified in the pdrstr command.
Updatable backup hold (WAIT mode)The system log from the point at which execution of the backup hold command began is required. Before executing backup hold, execute the pdlogls command to record the following information:
  • System log service run ID (Run ID)
  • System log file generation number (Gen No.)
  • System log file's file group name (Group)
Also record the date and time at which execution of backup hold began. Specify this time if the -T option is to be specified in the pdrstr command.
Updatable backup-holdRefer to the KFPS02183-I message, which indicates the starting position of the system logs needed for database restoration.*
The system log file file group name, generation number, and synchronization point dump acquisition start time indicated in the KFPS02183-I message output before the updatable backup-hold indicate the starting position of the system logs needed for database restoration. The system log service run ID can be checked with the pdlogls command.
Specify the synchronization dump acquisition start time if the -T option is to be specified in the pdrstr command.
The Logical Volume Manager (LVM) is used and the pdcopy command is executed in the updatable mode.Refer to the pdcopy command's processing results listing.

* When pd_spd_assurance_msg=N is specified, the KFPS02183-I message is not output.