The pdhold command shuts down specified RDAREAs. If a specified RDAREA is in use, the command shuts it down when its utilization is completed.
Shutdown without specifying any options other than -r is called command shutdown.
(a) -r {RDAREA-name[,RDAREA-name]...|ALL}
- RDAREA-name ~<identifier> ((1-30))
- Specifies the names of RDAREAs to be shut down. A shutdown achieved by specifying the -r option is called command shutdown.
- ALL
- Specifies that all RDAREAs are to be shut down. The following table describes the RDAREAs that are shut down depending on the combination of other options:
Other option | RDAREAs that are shut down |
---|
-b | All RDAREAs except list RDAREAs and temporary table RDAREAs |
Other | All RDAREAs except the master directory RDAREA |
- Rules:
- For the rules for specifying RDAREAs, see 1.5.2 Specification of RDAREAs in operation commands and utilities.
- If you specify the -b option, you can also specify a master directory RDAREA; otherwise, you cannot specify a master directory RDAREA. Note also that when you specify the -b option, you cannot specify a list RDAREAs or a temporary table RDAREA.
- If specifying a user RDAREA or user LOB RDAREA, make sure that the corresponding data dictionary RDAREA is in one of the following statuses:
Open and shutdown release status
Open and shutdown status placed by the pdhold command
- When specifying both data dictionary and user RDAREAs or both data dictionary and user LOB RDAREAs, be sure to specify the data dictionary RDAREAs last.
(b) -c
Specifies that the RDAREA is to be shut down and then closed. This is called closed command shutdown.
If this option is omitted, HiRDB shuts down only the specified RDAREAs.
(c) -i
Specifies that the RDAREAs that have been shut down are to be made available to users for referencing. This is called reference-possible shutdown.
If you omit this option, you cannot reference the RDAREAs shut down.
(d) -b [-w] [-u]
Specifies that the RDAREAs are to be placed in backup hold status.
The backup-hold status enables a backup copy to be made even in online mode. RDAREAs are placed in backup hold at the following times:
- When a backup is acquired in pdcopy's updatable mode
- When a backup is acquired using a method other than pdcopy, such as a general-purpose backup tool or OS command.
- When dual logical volumes are separated
There are four different backup-hold statuses:
- Reference-possible backup-hold (-b specified)
- Reference-possible backup-hold (update WAIT mode) (-b,-w specified)
- Updatable backup-hold (-b, -u specified)
- Updatable backup-hold (WAIT mode) (-b, -w, -u specified)
Statuses 1 and 2 above are called committing a database.
The following explains each backup-hold status:
- Reference-possible backup-hold
- If an updating transaction can result in an error until the shutdown status is released, place the RDAREA on reference-possible backup-hold.
- Notes
- For an RDAREA in the reference-possible backup-hold status, no deadlock occurs with an updating transaction.
- You can use the backup copy obtained in this status to restore the database to the point where the backup was made without having to use the system log. Using the system log existing immediately before the RDAREA was placed in the backup-hold status, you can restore the database to the point where the error occurred.
- You can reference an RDAREA on reference-possible backup-hold, but an attempt to update the RDAREA results in an SQL error (-920) unless the shutdown status is released. If an updating transaction in no-log mode results in an error, all updated RDAREAs, if any, are placed in shutdown status.
- Reference-possible backup-hold (update WAIT mode)
- If an updating transaction can be placed on hold until the shutdown status is released, place the RDAREA on reference-possible backup-hold (update WAIT mode).
- Notes
- You can use the backup copy obtained in this status to restore the database to the point where the backup was made without having to use the system log. Using the system log existing immediately before the RDAREA was placed on backup-hold, you can restore the database to the point of error occurrence.
- You can reference an RDAREA on reference-possible backup-hold (update WAIT mode), but an attempt to update the RDAREA results in the hold status unless the RDAREA is released from the backup-hold status. Therefore, the value of the pd_lck_wait_timeout operand in the system definitions and the value of PDCWAITTIME in the client environment definitions must be at least the period of time the backup-hold status is in effect. If timeout occurs, the updating transaction results in an SQL error (-770).
- If you place an RDAREA on reference-possible backup-hold (update WAIT mode), deadlock may occur with an updating transaction. By specifying pd_deadlock_priority_use=Y in the system definition and a deadlock priority value in the pd_command_deadlock_priority operand, you can specify whether the updating transaction or the operation command is to take control in the event of deadlock.
- If deadlock occurs, the backup-hold status placed by the pdhold command is released and the same backup-hold processing is repeated. You can use the backup copy obtained in this status to restore the database to the point where the backup was made. This retry processing is repeated up to five times. If deadlock occurs on the fifth retry, the system releases all the backup-hold statuses placed by the pdhold command and terminates the processing with an error.
- If an updating transaction in no-log mode terminates with an error due to timeout or deadlock, all updated RDAREAs, if any, are placed in shutdown status.
- Updatable backup-hold
- If you want to immediately place an RDAREA in backup-hold status and access it in this status, place the RDAREA in the updatable backup-hold status. If another command is executing, you can execute the pdhold command to place an RDAREA in updatable backup hold status after that command has terminated.
- Notes
- You can reference and update an RDAREA in the updatable backup-hold status.
- For an RDAREA on updatable backup-hold, an applicable page's physical log is output when the update buffer takes effect on the database, unless the shutdown status is released. Therefore, note the following:
(a) Check to see if there is enough space in the system log file.
(b) If updating a large amount of data, do not place the RDAREA on updatable backup-hold (a large amount of plug-in index data is also updated).
(c) Upon completion of backup processing, immediately release the RDAREA from the updatable backup-hold status.
- Even during the execution of updating transaction, the pdhold command can place an RDAREA on updatable backup-hold.
- To restore the database using the backup copy obtained in this status, you need the system log acquired after the backup processing and the previous synchronization point. However, if an updating transaction was executed in the pre-update log acquisition or no-log mode after the previous synchronization point, you cannot restore the database with this backup copy.
- Because physical logs are output when you update a shared RDAREA in the updatable backup-hold mode, more log information is output than when a shared RDAREA in a mode other than the updatable backup-hold mode is updated. If you acquire backups of a shared RDAREA in the updatable backup-hold mode, you should consider not executing update jobs at all, or at the least you should minimize the amount of data to be updated.
- Updatable backup-hold (WAIT mode)
- If an RDAREA can be placed in backup-hold status after completion of an updating transaction and you want to access the RDAREA in this status, place the RDAREA in the updatable backup-hold status (WAIT mode).
- Notes
- To restore the database using a backup copy obtained in this status, you do not need the system log if no warning message (KFPH00157-W) was output when the RDAREA was released from the backup-hold status. If a warning message was output, you need the system log existing after the previous synchronization point. Using the system log existing immediately before the RDAREA was placed in backup-hold status, you can restore the database to the point of error occurrence, whether or not a warning message was output. If the backup copy was made with pdcopy specifying -M s, you need the system log existing after the previous synchronization point, whether or not a warning message was output.
- If you place an RDAREA on updatable backup-hold (WAIT mode), you can reference and update the RDAREA.
- For an RDAREA on updatable backup-hold (WAIT mode), an applicable page's physical log is output when the update buffer takes effect on the database unless the shutdown status is released. Therefore, note the following:
(a) Check to see if there is enough space in the system log file.
(b) If updating a large amount of data, do not place the RDAREA on updatable backup-hold (a large amount of plug-in index data is also updated).
(c) Upon completion of backup processing, immediately release the RDAREA from the updatable backup-hold status.
- If updating transaction processing is underway, the pdhold command to place an RDAREA on updatable backup-hold (WAIT mode) is placed on hold until the transaction processing is completed.
- If an RDAREA is on updatable backup-hold, an updating transaction in pre-update log acquisition or no-log mode for this RDAREA is placed on hold until the RDAREA is released from the backup-hold status. Therefore, the value of the pd_lck_wait_timeout operand in the system definitions and the value of PDCWAITTIME in the client environment definitions must be at least the period of time the backup-hold status is in effect. If timeout occurs, the updating transaction in pre-update log acquisition or no-log mode results in an error.
- If you place an RDAREA on updatable backup-hold (WAIT mode), deadlock may occur with an updating transaction in the pre-update log acquisition or no-log mode. By specifying pd_deadlock_priority_use=Y in the system definition and a deadlock priority value in the pd_command_deadlock_priority operand, you can specify whether the updating transaction or the operation command is to take control in the event of deadlock.
- If deadlock occurs, the backup-hold status placed by the pdhold command is released and the same backup-hold processing is repeated. You can use the backup copy obtained in this status to restore the database to the point where the backup was made. This retry processing is repeated up to five times. If deadlock occurs on the fifth retry, the system releases all the backup-hold status placed by the pdhold command and terminates the processing with an error.
- If an updating transaction in pre-update log acquisition or no-log mode terminates with an error due to timeout or deadlock, all updated RDAREAs, if any, are placed in shutdown status.
- Because physical logs are output when you update a shared RDAREA in the updatable backup-hold mode, more log information is output than when a shared RDAREA in a mode other than the updatable backup-hold mode is updated. If you acquire backups of a shared RDAREA in the updatable backup-hold mode, you should consider not executing update jobs at all, or at the least you should minimize the amount of data to be updated.
- -w
- Specifies that the RDAREAs are to be placed on reference-possible backup-hold (update WAIT mode) or updatable backup-hold (WAIT mode).
- If you place the RDAREAs on reference-possible backup-hold (update WAIT mode), an updating transaction is placed on hold. If you place the RDAREAs on updatable backup-hold (WAIT mode), an updating transaction in pre-update log acquisition or no-log mode is placed on hold.
- -u
- Specifies that the RDAREAs are to be placed on updatable backup-hold.
- You can reference and update an RDAREA on updatable backup-hold. However, an attempt to update a UAP or utility in no-log mode is placed on hold until the shutdown status is released. If you omit this option, the system places the specified RDAREAs on reference-possible backup-hold.
- Rules of backup-hold
- While an RDAREA is in the backup-hold status, you cannot execute pdmod (to extend, reinitialize, or change the attributes of an RDAREA), pdload, or pdrorg (to reload) on the RDAREA.
- The status of an RDAREA on reference-possible backup-hold (update WAIT mode) or updatable backup-hold is not inherited during a rerun.
- If you place an RDAREA on updatable backup-hold during operation in the no-log mode, be sure to use the pdlogswap -d sys -w command to swap the system log files and validate the synchronization point dump beforehand. Otherwise, you need to use pdrstr to specify a range of recovery in the event of an error.
- If you terminate or restart HiRDB while making a backup copy in the updatable backup-hold status, the backup copy obtained cannot be guaranteed. In this case, obtain a backup copy again.
- For an RDAREA on reference-possible backup-hold (update WAIT mode), deadlock may occur between the pdhold command and an updating transaction. For an RDAREA on updatable backup-hold, deadlock may occur between the pdhold command and an updating transaction in the no-log mode. In the event of deadlock, if the RDAREA is already placed on reference-possible backup-hold (update WAIT mode) or updatable backup-hold, execute the pdrels command to release the RDAREA from the shutdown status and then re-execute the pdhold command. If the RDAREA has not been placed on reference-possible backup-hold (update WAIT mode) or updatable backup-hold, re-execute the pdhold command after a while.
- If update buffer contents become effective for an RDAREA while it is on updatable backup-hold (WAIT mode) status, a warning message (KFPH00157-W) is issued when the backup-hold status is released. If this warning message has not been issued, you can restore data to the point where the backup was made without using the system log. However, if this message has been issued, you need the system log obtained since the previous synchronization point. Whether or not the warning message has been issued, if you use the system log obtained immediately before the backup shutdown, you can restore data to the point where the error occurred. If you have acquired the backup using pdcopy with -M s specified, you need the system log obtained since the previous synchronization point whether or not the warning message has been issued.
- If the pdhold command that has been issued to place an RDAREA in backup hold status is placed in wait status by another command, the timeout specified in the pd_lck_wait_timeout operand in the system definition does not apply to this pdhold command. The command is kept in wait status until the RDAREA is released from the other command. You can terminate a pdhold command that is in wait status by executing the pdcancel command to end the single server process or back-end server process.