Previous | Contents | Index |
The SET NODE command sets various node-related options.
SET node
Command Qualifiers | Defaults |
---|---|
/AUTOISOLATE | /NOAUTOISOLATE |
/CLUSTER | /NOCLUSTER |
/INACTIVITY_TIMEOUT[=secs] | /INACTIVITY_TIMEOUT=60 |
/ISOLATE | /NOISOLATE |
/NODE=node-list | /NODE=default-node-list |
/OUTPUT[=file-spec] | /OUTPUT=stdout |
/RECOVERY=recovery-protocol | /RECOVERY=V40 |
The SET NODE command sets the automatic isolation characteristics and the link timeout default of a node.
/AUTOISOLATE
/NOAUTOISOLATE (D)
Any RTR node may disconnect a remote node if it finds the remote node is unresponsive or congested. The normal behavior following such action is automatic network link reconnection and recovery.Node autoisolation allows a node (the isolator) to disconnect a congested or unresponsive remote node (the isolatee) in such a way that when the congested node attempts to reconnect, it receives an instruction to close all its network links and cease connection attempts. A node in this state is termed isolated.
Some applications require that a node suspected of causing congestion (that is, not processing network data quickly enough) is isolated from the rest of the network, so as to cause minimum disruption. The node autoisolation feature meets this requirement.
Remote node autoisolation can be enabled (at the isolator) where it applies to all links using SET NODE/AUTOISOLATE, or for specific links only with the SET LINK/AUTOISOLATE command. An isolated node (isolatee) remains isolated until you perform both of the following actions:
- Enable the link to the isolated node on all nodes that have isolated it, that is set link [isolated-node]/enable
- Exit the isolated state on the isolated node, that is set node/noisolate
Autoisolation is disabled (at the isolator) using the /NOAUTOISOLATE qualifier.
/CLUSTER
/NOCLUSTER (D)
Specifies that the command is executed on all the nodes in the cluster.If neither /NODE nor /CLUSTER is specified, the command is executed on the nodes specified by the latest SET ENVIRONMENT command. If no SET ENVIRONMENT command has been entered, the command is executed only on the node where the command was issued.
Note
In environments that do not support clustering, the /CLUSTER qualifier causes the relevant command to be executed on the local node only./INACTIVITY_TIMEOUT[=secs]
/INACTIVITY_TIMEOUT=60
/INACTIVITY_TIMEOUT[=secs] specifies the link inactivity timeout value for all current links, and also sets the default inactivity timeout value for new links. The default value is 60 seconds.See SET LINK/INACTIVITY_TIMEOUT for further information.
/ISOLATE
/NOISOLATE (D)
The /ISOLATE qualifier is obsolete and is available for compatibility reasons only. Use /AUTOISOLATE instead.Use /NOISOLATE to take a node out of the isolated state. (See the /AUTOISOLATE qualifier for further information).
/NODE[=node-list]
/NODE=default-node (D)
Specifies that the command is executed on all nodes specified in node-list . If node-list is omitted, the command is executed only on the node where the command was issued./OUTPUT[=filespec]
/OUTPUT=stdout (D)
Specifies that the resulting information is written to the file filespec . If /OUTPUT or filespec is omitted, the standard or default output is used./RECOVERY=recovery-protocol
/RECOVERY=V40 (D)
The /RECOVERY qualifier is used to set the recovery protocol to that used in RTR Version 3.2 and earlier and is used during rolling upgrades to RTR Version 4.0. If an RTR environment has many facilities with different mixes of backend and router roles on a node (making it difficult to satisfy the conditions for a rolling upgrade), use this command to set the recovery protocol to V3.2. Once the upgrade is completed, you can revert to using the V4.0 recovery protocol by omitting this command the next time RTR is started. The protocol will default to V4.0.RTR must be started for this command to have any effect. The recovery protocol must be specified before any recovery is initiated by RTR, therefore this command must be entered before any facilities are defined.
You can display the recovery protocol that is in effect for RTR by using the RTR node counter:
RTR> SHOW RTR/COUNTER=CRM_BE_RECOVERY_PROTOCOL
RTR> SET NODE /NOISOLATE |
This command tells RTR to set the executing node non-isolated.
The SET PARTITION command sets various partition-related options.
SET PARTITION partition-name
Command Qualifiers | Defaults |
---|---|
/FACILITY[=facility_name] | /FACILITY=RTR$DEFAULT_FACILITY |
/FAILOVER_POLICY= | None |
(SHADOW|STAND_BY) | |
/IGNORE_RECOVERY | /NOIGNORE_RECOVERY |
/PRIORITY_LIST= | None |
(BE-node1,BE-node2,...) | |
/RECOVERY_RETRY_COUNT=n | No limit |
/RESTART_RECOVERY | None |
/RESUME | None |
/SHADOW | /NOSHADOW |
/SUSPEND | None |
/TIMEOUT=nn | None (nn in seconds) |
The SET PARTITION command sets the characteristics of a named partition. Only backend partitions may be manipulated with this command; the command must be entered on the backend where the partition is located.Use SET PARTITION any time after the partition has been created (either explicitly by CREATE PARTITION or implicitly by starting a server.) Note that the command only takes effect after the first server joins a partition. Any errors encountered at that time will appear as RTR log file entries. Using SET PARTITION to change the state of the system results in a log file entry.
See Chapter 3, Partition Management for a more detailed description of situations where the SET PARTITION command might be used.
partition-name
The name of the partition being manipulated. This can be specified as partition_name (if the partition name is unique on the node), or as facility_name:partition_name .
/FACILITY=facility_name (D)
Determines the facility that the partition command will act on. This is required./FAILOVER_POLICY=SHADOW
/FAILOVER_POLICY=STAND_BY (D)
Determines the action to take when the primary partition fails. The default action is to allow a standby of the primary to become the new primary. Optionally, RTR can be set to change state so that the secondary becomes primary, and a standby of the old primary (if any) becomes the new secondary.If the /FAILOVER qualifier is used once on any backend, it affects all other partition instances with the same key range.
/IGNORE_RECOVERY
/NOIGNORE_RECOVERY (D)
Forces the partition to exit any current wait state it may be in.If a partition should enter a wait state or fail because of the unavailability of either a local or remote journal, use this command to override the default RTR behavior. It instructs RTR to skip the current step in the recovery process. Since this command bypasses parts of the recovery cycle, use it with caution, and only when availability is more important than consistency in your application databases.
This qualifier applies only to the backend on which the command is entered.
/PRIORITY_LIST=(BE-node1,BE-node2,...)
Sets a relative priority that is used by RTR when selecting a backend member to make active. Enter a list of the backends in your configuration in decreasing order of priority; the relative order of the list will be taken into consideration when RTR is determining on which node to make a partition active. This qualifier applies only to the backend on which the command is entered, and should be entered in the same form on all backends.It is not an error to enter different versions of the priority list at different backends, but this is not recommended. Compaq recommends that you suspend partitions before changing the priority list.
/RECOVERY_RETRY_COUNT=n
If an application server dies while processing a transaction recovered from the journal, RTR will present the transaction to another (concurrent or standby) server. The RECOVERY_RETRY_COUNT indicates the maximum number of times the transaction is presented to a server for recovery before being written to the journal as an exception.There are two types of recovery operations where transactions are recovered from journal: local recovery and shadow recovery. Shadow recovery is the process of recovering the remembered transactions written to a primary shadow journal while the secondary shadow site is down.
The SET PARTITION /RECOVERY_RETRY_COUNT parameter does not have any affect on remembered transactions recovered during shadow recovery. That is, if there is a killer transaction remembered in the journal on a primary shadow node, on this node RTR does not count the number of times the transaction is recovered by a recovering secondary shadow node. The way to ensure that a remembered transaction will be exceptioned by RTR is by starting a sufficient number of concurrent servers on the recovering secondary shadow node.
For this reason, Compaq recommends that the number of concurrent secondary shadow servers started is greater than the value set for the RECOVERY_RETRY_COUNT on a partition. This will ensure that a remembered (killer) transaction being recovered from a primary shadow journal will be exceptioned if the retry limit is exceeded.
Note that only those transactions that have reached voting stage on a server can be exceptioned. If a server always dies before voting on a transaction, the transaction will be aborted by RTR after the third try. This is a hard-coded limit (the so-called "three strikes and you're out" feature).
/RESTART_RECOVERY
Restarts the recovery cycle. The recovery cycle can be manually restarted with /RESTART. This is useful if the operator previously aborted recovery through use of /IGNORE_RECOVERY. Since this command may result in recovery of transactions from previously inaccessible journals, it should not be used if your applications are sensitive to the order in which transactions are processed by the servers. This qualifier applies only to the backend on which the command is entered./RESUME
Resume normal operations (that is, cancel a /SUSPEND command). If the partition is already in the desired state, the command has no effect. This qualifier applies only to the backend on which the command is entered./SHADOW
/NOSHADOW
Turns shadowing on or off for the specified partition.Shadowing for a partition can be turned off only in the absence of an active secondary site, that is, the active member must be running in remember mode. The command will fail if it is entered on either an active primary or secondary. If entered on a standby of either the primary or secondary, the command is accepted but fails in the RTR router; this is recorded with a log file entry at the router. Once shadowing is disabled, the secondary site servers will be unable to start up in shadow mode until shadowing is enabled again.
Shadowing for the partition can be turned on by entering the command at the current active member or any of its standbys.
If the /SHADOW qualifier is used once on any backend, it affects all other partition instances with the same key range.
If shadowing is already in the desired mode, the command has no effect.
/SUSPEND
Stops presenting new transactions on the specified partition until a /RESUME is issued.Use /SUSPEND to temporarily halt the presentation of new transactions to servers on the backend where the command is entered. The command completes when the processing of all currently active transactions is complete. This qualifier applies only to the backend on which the command is entered.
The optional /TIMEOUT qualifier may be used to limit the time in seconds that the command waits for completion. If the command times out, presentation of new transactions is suspended, but there still exist transactions for which servers have yet to complete processing. The operator must decide to either reenter the command and wait a longer period of time, or resume the partition. Using this command does not affect any transaction timeout value specified by RTR clients, so such transactions may encounter a timeout condition if the partition remains suspended.
/TIMEOUT
See description for /SUSPEND.
The SET TRANSACTION command sets various transaction-related options.
SET TRANSACTION [transaction-id]
Command Qualifiers | Defaults |
---|---|
/BEFORE[=date] | Today |
/FACILITY=facility_name | /FACILITY=RTR$DEFAULT_FACILITY |
/NEW_STATE=new_state | None |
/NODE[=node_list] | /NODE=default_node |
/OUTPUT[=filespec] | /OUTPUT=stdout |
/PARTITION=partition_name | None |
/SINCE[=date] | Today |
/STATE=current_state | None |
/USER=username | All users |
The SET TRANSACTION command allows you to modify the state of a transaction or set of transactions stored in the RTR journal.
Caution
The SET TRANSACTION command could damage your journal and database integrity if used incorrectly. Ensure that you fully understand the reason and impact for changing a transaction state before altering your RTR system.This command is complementary to the DUMP JOURNAL and SHOW TRANSACTION commands in that it gives capability of reading and modifying the status of a transaction status in the RTR journal. For example, if a shadow recovery is known to be unnecessary, you may want to clean up the RTR journal to prevent the committed transactions in the journal from being replayed. Using the SET TRANSACTION command, the RTR administrator is able to delete that set of transactions from the journal.
In addition, the SET TRANSACTION command also helps users to better control the RTR runtime environment in difficult operational situations. For example, a transaction that is still in SENDING state on the backend may appear to be hung and cannot proceed. Using the SET TRANSACTION command, an RTR administrator can abort this transaction "on-the-fly" and free runtime resources.
While the SET TRANSACTION command enables RTR users to have full control of RTR transactions, it introduces the risk that a transaction could be lost or corrupted. The command must be used with discretion and only by experienced RTR system administrators.
After the SET TRANSACTION command completes, you may use the DUMP JOURNAL command to verify the results.
Refer to Chapter 4, Transaction Management, for more information about transaction management and the SET TRANSACTION command.
The command can only be executed on a backend node in which the journal is located and the RTR log file must be turned on to record the transaction changes. RTR needs to be started before using this command.
When you modify a transaction's state, you must specify the qualifier /PARTITION in addition to the required qualifers /STATE and /NEW_STATE. Specifying this information ensures that RTR locates the specific transaction branch.
When a transaction's state is changed, the new state is written to the RTR journal synchronously. RTR will try to determine whether the change also affects other portion of the RTR environment. For example, in a runtime situation where RTR routers and RTR backend servers are active, the RTRACP will send the new status to application servers as well as RTR routers to make sure that the change takes effect on all nodes in the RTR facility or facilities.
However, in an off-line situation where an RTR facility has not been created, RTR will simply update the transaction state in place in the RTR journal. The RTR log file must be turned on before using the SET TRANSACTION command to record the state changes. See the SET LOG command.
There are eight legitimate situations where you can change a transaction's state. See Table 7-19.
transaction-id
Specifies a particular transaction or transactions whose transaction state you want to change. The transaction_id format is the same as that displayed by the DUMP JOURNAL and SHOW TRANSACTION commands.If no transaction_id is specified, all transactions (*) that satisfy the specifying qualifiers are processed by the command.
/BEFORE[=date]
Selects only those transactions whose timestamp is before the specified date. Default is the current date./FACILITY
/FACILITY=RTR$DEFAULT_FACILITY (D)
Specifies the name of a facility for selecting transactions. The default facility, RTR$DEFAULT_FACILITY, is used if this qualifier is not specified./NEW_STATE
Specifies the new transaction state that selected transactions will be changed to. This qualifier is required and new state value must be specified.Value of new_state may be one of the following:
ABORT
COMMIT
DONE
EXCEPTIONNote that one cannot always change a transaction's state from one legitimate transaction state to another. Some state changes are not valid. The following table shows state changes that are valid.
Table 7-19 Valid Transaction State Changes NEW STATE Current State COMMIT ABORT EXCEPTION DONE SENDING YES VOTED YES YES COMMIT YES YES EXCEPTION YES YES PRI_DONE YES /NODE[=node-list]
/NODE=default-node (D)
Specifies that the command is executed on all nodes specified in node-list . If node-list is omitted, the command is executed only on the node where the command was issued./OUTPUT[=filespec]
/OUTPUT=stdout (D)
Specifies that the resulting information is written to the file filespec . If /OUTPUT or filespec is omitted, the standard or default output is used./PARTITION
/PARTITION=partition_name
Specifies the name of a partition within which all transactions are running. A partition name must be supplied.Use SHOW PARTITION to view the names of the currently active partitions.
/SINCE[=date]
Selects only those transactions whose timestamp is after the specified date. Default is the current date./STATE=current_state
Selects a particular transaction or a set of transactions that are in the specified current_state transaction state. This qualifier is required and the current_state value must be specified.Value of current_state may be one of the following:
SENDING
VOTED
COMMIT
EXCEPTION
PRI_DONEUse the SHOW TRANSACTION command to help you find what is the current state of a particular transaction.
/USER[=user-id]
/USER=all users (D)
Allows you to select transactions that were initiated by a client process.
If /USER is not specified, transactions for all users are affected.
RTR> SET TRANSACTION "50d01f10,0,0,0,0,2166,522b2001" - _RTR> /NEW=ABORT /STATE=SENDING /PART=DB_PART |
Abort this specified transaction running in the DB_PART partition.
RTR> SET TRANSACTION /NEW=ABORT /STATE=VOTED /PART=DB_PART |
Abort all transactions that are in VOTED transaction state and are running in DB_PART partition, in the RTR$DEFAULT-FACILITY facility.
For more examples, refer to Chapter 4, Transaction Management.
Previous | Next | Contents | Index |