The following table explains the four types of backup-hold.

Table 6-5 Types of backup-hold

Backup-hold type	Explanation
Reference-possible backup-hold	During 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 might 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-hold	During 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 might 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 HiRDB Version 9 Staticizer Option Description and User's Guide.

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.

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 (for example, 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 might 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. The following table shows backup-hold status inheritance during HiRDB reactivation.
   

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

   Backup-hold type	Backup-hold status inheritance during reactivation
   Reference-possible backup-hold	Yes
   Reference-possible backup-hold (update WAIT mode)	No
   Updatable backup-hold	No
   Updatable backup-hold (WAIT mode)	No

Yes: Status is inherited.

No: Status is not inherited.

(a) Lock-release timeout during backup-hold

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

• Reference-possible backup-hold (update WAIT mode)
• Updatable backup-hold
• Updatable backup-hold (WAIT mode)

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:

• Reference-possible backup-hold (update WAIT mode)
• Updatable backup-hold
• Updatable backup-hold (WAIT mode)

In the reference-possible backup-hold (update WAIT mode) mode, deadlock with an updating transaction might occur. In the updatable backup-hold and updatable backup-hold (WAIT mode) modes, deadlock might 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 might 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 configuration, 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.

When the database is updated during updatable backup-hold, additional system logs are output. For details about how to estimate the volume of the additional system logs that are output, see Amount of system log information output during an updatable backup hold in the HiRDB Version 9 Installation and Design Guide. If HiRDB is abnormally or forcibly terminated during backup-hold, the backup-hold is not inherited when HiRDB restarts (excluding reference-possible backup-hold). Therefore, no additional system logs are output.

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. The following table shows how to determine which system logs are needed for database restoration.

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

Condition	Determining 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: Log server process 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: Log server process 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-hold	Refer 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. To check the log server process run ID, use 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.