(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 the -q and other options:
Other option | -q option omitted | -q option specified |
---|
-b | All RDAREAs except list RDAREAs and temporary table RDAREAs | RDAREAs of the specified generation in the inner replica group |
-s | When the -s option is specified, the -q option cannot be omitted. |
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.
- If you are using the inner replica facility, you can also specify the original and replica RDAREA names. In this case, you can specify only user RDAREAs and user LOB RDAREAs.
(b) -q generation-number ~<unsigned integer> ((0-10))
Specifies a replica RDAREA generation number.
If you specify this option, make sure that the original RDAREA name is specified in the -r option. An error results if you specify an original RDAREA whose replicas have all been deleted or if you specify an RDAREA without a replica RDAREA.
(c) -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.
(d) -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.
(e) -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.
- You cannot place in backup hold status an RDAREA that has been placed temporarily in reference-possible shutdown status from online reorganization hold status. To determine whether or not an RDAREA is in online reorganization hold status, use the pdls -d org command.
(f) -s
Specifies that the RDAREAs are to be placed in synchronization shutdown status.
Synchronization shutdown is used when the inner replica facility is used. RDAREAs are placed in synchronization shutdown status, for example, when data in an RDAREA is to be copied as the data in another generation of RDAREA within the same inner replica group (for re-pairing paired volumes).
When an RDAREA is placed in synchronization shutdown status, the buffers for the corresponding RDAREA are discarded and the referencing and updating transactions are placed in wait status.
- Rules
- If an RDAREA is placed in synchronization shutdown status, conformity is lost in the contents of the RDAREA because the update buffer for that RDAREA is discarded without being applied to the database. If there is an update buffer, inconsistent information is written into the RDAREA. You cannot release this synchronization shutdown status until data is copied from another RDAREA to the corresponding RDAREA within the same inner replica group to achieve data conformity.
- An error results if you specify this option, and the following RDAREAs are specified in the -r option:
- RDAREAs for which replica definition is not supported (for details about RDAREAs for which replica definition is supported, see the HiRDB Version 9 Staticizer Option Description and User's Guide).
- Original RDAREAs all of whose replica RDAREAs have been deleted, or RDAREAs that do not have replica RDAREAs
- If you specify this option and multiple RDAREAs are specified in the -r option, the command executes the processing in the batch mode for each server. If an error occurs during processing, the command ignores the processing at the server containing the erroneous RDAREA, and resumes processing at the other servers.
- While synchronization shutdown is in effect, you cannot execute pdmod (to extend or delete RDAREAs or change their attributes), pdload, pdrorg, or pdcopy.
- Once an RDAREA is placed in synchronization shutdown status, it is also locked in the same manner as with reference-possible backup hold (update WAIT mode). Therefore, the values of the pd_lck_wait_timeout operand in the system definition and PDCWAITTIME in the client environment definition must be no less than the duration of the synchronization shutdown. If a timeout occurs, a referencing or updating transaction results in an SQL error (-770).
- If an RDAREA is placed in synchronization shutdown status, deadlock may occur for a referencing or 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 referencing or updating transaction or the operation command is to take control in the event of deadlock. If the operation command results in an error due to deadlock, re-execute the pdhold command after a specific period of time. If the pdhold -s command with multiple RDAREAs specified results in an error, synchronization shutdown processing is ignored for all the RDAREAs.
- If an updating transaction running in the no-log mode terminates with an error due to a timeout or deadlock and if there is an RDAREA that has already been updated by the transaction, that RDAREA will be placed in no-log shutdown status.
- To perform the synchronized shutdown of multiple related RDAREAs, such as those containing a table and its index, use only one pdhold command.
- If the pdhold -s command is executed, the RDAREAs are forcibly released from memory. If this happens, update data in in-memory data buffers is not applied to the RDAREAs.
(g) -W execution-monitoring-interval ~<unsigned integer> ((0 to 3600))
Specifies (in minutes) the monitoring interval when the execution time of the pdhold command is to be monitored. For guidelines on the value to specify and details about the resulting operation, see the description of the pd_cmd_exec_time operand in the system common definition in the manual HiRDB Version 9 System Definition.
If 0 is specified in this option, the command's execution time is not monitored.
If this option is omitted, the value of the pd_cmd_exec_time operand in the system common definition takes effect.