- -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.
- You can also use batch specification of RDAREA names. For details about batch specification of RDAREA names, see 1.5.2 Batch specification of RDAREA names in operation commands.
- 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 | 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:
- If you specify the -b option, you can also specify a master directory RDAREA; otherwise, you cannot specify a master directory RDAREA. Additionally, if you specify the -b option, you cannot specify a list RDAREA.
- You cannot specify a duplicated RDAREA name. If specified, the system will eliminate all duplicated RDAREA names.
- You can specify a maximum of 128 RDAREAs. If more than 128 RDAREA names are specified, the system ignores the excess names.
- If an RDAREA name is enclosed in double quotation marks ("), the system treats it as being case sensitive; otherwise, the system treats it as all uppercase letters. If an RDAREA name contains a blank, enclose the entire name in double quotation marks ("). If you use the Bourne shell (sh), C shell (csh), or Korn shell (ksh), you need to enclose the RDAREA name in single quotation marks (').
- 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.
- -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 a normal RDAREA (one without a replica RDAREA).
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.
Specifies that the RDAREAs that have been shut down are to be made available to users for referencing. This is called reference-possible command shutdown.
If you omit this option, you cannot reference the RDAREAs shut down.
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
For example, specify this option to back up RDAREAs using JP1/OmniBack II's backup acquisition facility.
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.
- Shared RDAREAs cannot be placed in updatable backup-hold status.
- 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.
- Shared RDAREAs cannot be placed in updatable backup-hold (WAIT mode) status.
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.
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. To terminate the pdhold command in wait status, use the pdcancel command to end the 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.
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 other than user RDAREAs or user LOB RDAREAs
- 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.