The SET LOG command specifies where RTR writes its log messages.

Format

SET LOG

Description

The SET LOG command specifies where RTR writes its log messages. You can write log messages to the operator console and to a maximum of four log files. Log files must be periodically purged to avoid difficulties with full disks. Do this by using SET LOG to specify a new file and deleting the old one.

If neither the /OPERATOR nor the /FILE qualifier is specified, logging is suppressed.

Note Log files must always be accessible even if a node fails.

Qualifiers

/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 remote command capability, the /CLUSTER qualifier causes the relevant command to be executed on the local node only. See Section 1.4 for more information.

/FILE=filespec-list

/NOFILE (D)

Specifies the names of up to four files where the log messages are written. The given file name is appended with .log.

/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.

/OPERATOR

/NOOPERATOR (D)

Specifies that messages are written to the operator log.

/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.

Related commands

• SHOW LOG

Examples

 RTR> SET LOG/FILE=RTRLOG.LOG/OPERATOR
      

This command tells RTR to write log messages to the file RTRLOG.LOG and to the operator log.

 RTR> SET LOG/NOFILE/NOOPERATOR
      

This command suppresses all RTR log messages.

 RTR> SET LOG/FILE="/usr/users/rtruser/daily_logfile"
      

This command tells RTR to write log messages to the file /usr/users/rtruser/daily_logfile.log .

 RTR> SET LOG/FILE=("logfile1.log","logfile2.log")
      

This command tells RTR to write log messages to logfile1.log and logfile2.log .

 RTR> SET LOG/OPERATOR
      

This command tells RTR to write log messages to the system log.

The SET MODE command specifies whether RTR should run in a group mode or the nogroup (system) mode.

Format

SET MODE

Description

The SET MODE command specifies whether RTR runs in group mode or nogroup mode. (Nogroup mode is the same as system mode.)

Production systems use RTR in the default (that is, nogroup or system) mode, whereby all users running in this mode use one common invocation of RTR.

Developers typically have their own invocation of RTR to avoid their RTR actions affecting other developers or the production system. This mode is termed group mode. Group mode allows development or testing of applications by several groups of people on the same system without interference.

Qualifiers

/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 remote command capability, the /CLUSTER qualifier causes the relevant command to be executed on the local node only. See Section 1.4 for more information.

/GROUP[=user-id

/NOGROUP

/GROUP specifies that RTR be set to GROUP mode for the user who issues the command. The group name defaults to the first eight characters of your current user-id. You may also change to another group by entering a user or group ID. Note that group names are used for naming RTR journal files; do not use a group name containing the string SYSTEM or conflicts may occur.

RTR> set mode/group=develpr

/NOGROUP sets RTR into NOGROUP mode.

/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.

Related commands

• SHOW MODE

Examples

 RTR> SET MODE/GROUP
      

This command tells RTR to enter GROUP mode.

 RTR> SET MODE/NOGROUP
      

This command tells RTR to enter NOGROUP mode.

The SET NODE command sets various node-related options.

Format

SET node

Description

The SET NODE command sets the automatic isolation characteristics and the link timeout default of a node.

Qualifiers

/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 remote command capability, the /CLUSTER qualifier causes the relevant command to be executed on the local node only. See Section 1.4 for more information.

/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

Related commands

• SHOW NODE
• SET LINK

Examples

 RTR> SET NODE /NOISOLATE
      

This command tells RTR to set the executing node non-isolated.

The SET PARTITION command sets various partition-related options.

Format

SET PARTITION partition-name

Description

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.

Parameters

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 .

Qualifiers

/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.

Related commands

• CREATE PARTITION
• SHOW PARTITION

The SET TRANSACTION command sets various transaction-related options.

Format

SET TRANSACTION [transaction-id]

Description

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.

Usage Notes

The command can only be executed on a backend node on 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 qualifiers /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 portions 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.

Parameters

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.

Qualifiers

/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.

---

Previous

Next

Contents

Index