Nonstop Database, HiRDB Version 9 Command Reference

[Contents][Index][Back][Next]

2.23 pddbchg (Change the replica status of replica RDAREAs)

Organization of this section
(1) Function
(2) Executor
(3) Format
(4) Options
(5) Rules
(6) Notes

(1) Function

The pddbchg command changes the replica status of replica RDAREAs (from sub-RDAREA to current RDAREA).

You can use the pddbchg command when HiRDB Staticizer Option has been installed.

(2) Executor

HiRDB administrator

(3) Format

 
 pddbchg -q generation-number -r {RDAREA-name[,RDAREA-name]...|ALL} [-w][-W execution-monitoring-interval]
 

(4) Options

(a) -q generation-number ~<unsigned integer> ((0-10))

Specifies the generation number of RDAREAs that are to be current RDAREAs.

(b) -r {RDAREA-name[,RDAREA-name]...|ALL}

RDAREA-name ~<identifier> ((1-30))
Specifies the original name of an RDAREA that is to be a current RDAREA. You can specify user RDAREAs and user LOB RDAREAs.

ALL
Specifies that all replica RDAREAs with the generation number specified in the -q option are to be switched to current RDAREAs.

Rules
For the rules for specifying RDAREAs, see 1.5.2 Specification of RDAREAs in operation commands and utilities
(c) -w

Specifies that if a specified RDAREA is locked, the command is to wait until the RDAREA is unlocked or until the value specified in the pd_lck_wait_timeout operand of the system definition operand is reached.

If you omit this option and a specified RDAREA is locked by another transaction, the command terminates with an error.

(d) -W execution-monitoring-interval ~<unsigned integer> ((0 to 3600))

Specifies (in minutes) the monitoring interval when the execution time of the pddbchg 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.

(5) Rules

  1. The pddbchg command can be executed only while HiRDB is active.
  2. The pddbchg command must be executed at the server machine that contains the single server or where the system manager is located.
  3. When you execute the pddbchg command, the data dictionary RDAREA must be in one of the following statuses:
    • Open and shutdown release status
    • Open, and with shutdown status placed by the pdhold command
  4. The pddbchg command enables you to change a current RDAREA regardless of the status of the RDAREA because the command does not check the status of the existing and new current RDAREAs.
  5. You cannot use the pddbchg command on an original RDAREA that employs updatable online reorganization.
  6. If the pddbchg command is executed on a shared RDAREA, all back-end servers are locked. If there can be multiple concurrent accesses to the corresponding RDAREA, global deadlock may occur, resulting in a timeout. If global deadlock has occurred, re-execute the pddbchg command.

(6) Notes

  1. The result of the pddbchg command can be checked by the pddbls command.
  2. Resources are locked as described below while the pddbchg command is executing:
    • Because inner replica configuration resources are locked while the pddbchg command is executing, a command that changes the inner replica configuration (such as changing the current RDAREA, defining and deleting replicas, or performing updatable online reorganization) is placed in lock-release wait status.
    • Because replica group configuration resources are locked while the pddbchg command is executing, a UAP that accesses an inner replica group in the RDAREA that is to be made the current RDAREA is placed in lock-release wait status.
    For details about locking during execution of the pddbchg command, see B.1 Lock mode for operation commands.
  3. The following describes the relationship among the pddbchg command, transactions, and utilities in terms of the lock-release wait status:
    • pddbchg command processing when another transaction or utility is accessing the current RDAREA
      When the -w option is specified
      The pddbchg command is placed in lock-release wait status for all locked resources until the value specified in the pd_lck_wait_timeout system definition operand is reached or the transaction accessing the resources terminated.
      When the -w option is not specified
      The pddbchg command terminates with an error if another transaction is accessing the data dictionary table, the server containing a specified original RDAREA, a new current RDAREA, or an existing current RDAREA.
    • Other transaction's or utility's processing when the pddbchg command is accessing the current RDAREA
      Another transaction or utility is placed in wait status until the pddbchg command terminates or the value specified in the pd_lck_wait_timeout system definition operand or the PDCWAITTIME client environment definition operand is reached.
  4. When the pddbchg command is executed, 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.
  5. If an error occurs during pddbchg command processing, the processing is cancelled for each server that contains an RDAREA being processed. If this happens, the pddbchg command resumes processing at the other servers.
  6. The following shows the pddbchg command's return code:
    0: Normal termination
    4: Warning termination (some RDAREA processing terminated with an error)
    8: Abnormal termination
    12: Abnormal termination (an event occurred that prevented output of the error message)
    If the error code is 12, check the error message in syslogfile at the host where the single server or dictionary server is located, eliminate the cause of the error, and then re-execute the command. If no error message has been output to syslogfile, contact the customer engineer.