Document revision date: 15 July 2002

This chapter describes what you must do if you want to run software that uses DECdtm services, such as ACMS, DECintact, Oracle Rdb, and RMS Journaling.

Information Provided in This Chapter

This chapter describes the following tasks:

Task	Section
Planning transaction logs	Section 27.2
Planning for a DECnet-Plus network	Section 27.3
Creating transaction logs	Section 27.4
Monitoring transaction performance	Section 27.5
Checking whether a transaction log is too small	Section 27.6
Changing the size of a transaction log	Section 27.7
Moving a transaction log	Section 27.8
Dismounting a disk	Section 27.9
Adding a node	Section 27.10
Removing a node	Section 27.11
Disabling DECdtm services	Section 27.12
Enabling DECdtm services	Section 27.13
Using the XA Gateway (Alpha only)	Section 27.14

The map in Figure 27-1 shows the tasks, and the order in which to do them.

This chapter explains the following concepts:

Concept	Section
Understanding transaction logs	Section 27.1
Understanding transaction groups	Section 27.3.2.2

Figure 27-1 Managing DECdtm Services

27.1 Understanding Transaction Logs

Before a node can execute DECdtm transactions, you must create a transaction log for the node. In an OpenVMS Cluster, create a transaction log for each node in the cluster. Use the Log Manager Control Program (LMCP) utility to create and manage transaction logs.

DECdtm services use the logical name SYS$JOURNAL to find transaction logs. You must define SYS$JOURNAL to point to the directories that contain transaction logs.

27.2 Planning Transaction Logs

The size and location of a transaction log can affect transaction performance. Before you create a transaction log, decide the size and location of the transaction log.

Later, you can change the size of a transaction log, or move it. However, careful planning at this stage reduces the need for future changes.

This section describes:

Task	Section
Deciding the size of a transaction log	Section 27.2.1
Deciding the location of a transaction log	Section 27.2.2

27.2.1 Deciding the Size of a Transaction Log

When you create a transaction log, you can specify its size. The default size is 4000 blocks; this gives acceptable performance on most systems.

If you know the expected rate of transactions, Compaq suggests the following formula to calculate the transaction log size:
size = 40 * rate
where:

size	is the size of the transaction log in blocks.
rate	is the average number of transactions executed per second.

If you do not know the rate of transactions, accept the default size of 4000 blocks.

27.2.2 Deciding the Location of a Transaction Log

You may need to choose between speed and either availability or reliability. For example, if the node is a workstation, you may choose to sacrifice speed for availability and reliability by putting the node's transaction log on a shadowed HSC--based disk, instead of on a faster disk attached to the workstation.

In a cluster environment, try to distribute the transaction logs across different disks. Having more than one transaction log on a disk can lead to poor transaction performance.

This section contains the following information to help you plan for using DECdtm in a DECnet-Plus network:

• Planning your DECnet-Plus namespace
• Planning SCSNODE names in your DECnet-Plus network

DECdtm does not support multiple DECnet-Plus namespaces.

This means that if you want to use software that uses DECdtm services, you cannot use both a local namespace and a DECdns namespace.

27.3.2 Planning SCSNODE Names in Your DECnet-Plus Network

SCSNODE is a system parameter that defines the name of the computer. You must follow certain rules when choosing SCSNODE names if you have a DECnet-Plus network and you want to perform DECdtm transactions that span either different OpenVMS Clusters or different standalone computers.

27.3.2.1 Rules for SCSNODE Names

• The SCSNODE name of each computer in a transaction group must be different from:
  • The SCSNODE names of the other computers in the transaction group; SCSNODE names must be unique within a transaction group
  • The DECnet simple names of other computers on the same local root
  • The DECnet synonyms of the other computers in the entire network
  
  For an explanation of transaction groups, see Section 27.3.2.2.
• If a computer is in an OpenVMS Cluster, its SCSNODE name must also be different from:
  • The DECnet simple names of the other computers in the same cluster
  • The DECnet simple names of computers on the same local root as other cluster members

A transaction group is a group of computers involved in DECdtm transactions whose SCSNODE names must obey the rules described in Section 27.3.2.1.

A transaction group conforms to the following guidelines:

• Each computer belongs to no more than one transaction group.
• All the computers in an OpenVMS Cluster belong to the same transaction group.
• If a single transaction spans computers A and B, then computers A and B belong to the same transaction group.

Figure 27-2 shows an example of a transaction group.

Figure 27-2 Transaction Group

All nine computers shown in the figure are in the same transaction group because:

• A transaction spans a computer in cluster FRED and a computer in cluster BILL. This means that the four computers in cluster FRED and the four computers in cluster BILL are in the same transaction group.
• A transaction spans standalone computer TOM and a computer in cluster BILL. This means that the standalone computer TOM is in the same transaction group as the computers in cluster BILL.

Before a node can perform DECdtm transactions, you must create a transaction log for the node. In an OpenVMS Cluster environment, create a transaction log for each node.

How to Perform This Task

1. For each node, decide the size and location of the transaction log, using the guidelines in Section 27.2. Remember that the disks must have enough contiguous space to hold the transaction logs.
2. If you are in a cluster environment, make sure that the disks on which you want to create the transaction logs are mounted clusterwide.
3. Decide in which directories you want to create the transaction logs. You may want to create new directories for the transaction logs.
4. Define SYS$JOURNAL to point to the directories in which you want to create the transaction logs:

   DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL dirspec[,...]

   where dirspec is the full specification of a directory in which you want to create one or more transaction logs. List all the directories that will contain transaction logs. You can list the directories in any order.
   In a cluster environment, use SYSMAN to define SYS$JOURNAL clusterwide.

5. Edit the SYS$MANAGER:SYLOGICALS.COM command procedure to include the SYS$JOURNAL definition.
   If you created node-specific versions of SYLOGICALS.COM, edit all the versions.
6. Create one transaction log for each node, using LMCP's CREATE LOG command:

   CREATE LOG [/SIZE=size] dirspecSYSTEM$node.LM$JOURNAL

   where:

   size	is the size of the transaction log in blocks. By default, the size of the transaction log is 4000 blocks.
   dirspec	is the full specification of the directory in which you want to create the transaction log.
   node	is the name of the node.

7. Make sure DECdtm services are enabled as follows:

   Step	Action
   a.	Check whether the logical SYS$DECDTM_INHIBIT is defined: $ SHOW LOGICAL SYS$DECDTM_INHIBIT
   b.	Is SYS$DECDTM_INHIBIT defined? Yes DECdtm services are disabled. Enable DECdtm services by following the instructions in Section 27.13. No DECdtm services are enabled.

Example

This example shows how to create transaction logs in an OpenVMS Cluster that consists of two nodes whose SCSNODE names are BLUE and RED. Neither node has a node-specific version of SYLOGICALS.COM.

Decide the size and location of the transaction logs:

Node	Size of Log (in Blocks)	Disk
BLUE	5000	DUA1
RED	4000	DUA2

Mount the disks clusterwide:

$ MOUNT/CLUSTER/SYSTEM DUA1: LOG1 $ MOUNT/CLUSTER/SYSTEM DUA2: LOG2

Create directories for the transaction logs:

$ CREATE/DIRECTORY DISK$LOG1:[LOGFILES] $ CREATE/DIRECTORY DISK$LOG2:[LOGFILES]

Define SYS$JOURNAL:

$ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL - _SYSMAN> DISK$LOG1:[LOGFILES], DISK$LOG2:[LOGFILES] SYSMAN> EXIT

Edit the SYS$MANAGER:SYLOGICALS.COM command procedure to include the following line:

$ ! $ DEFINE/SYSTEM/EXECUTIVE_MODE SYS$JOURNAL DISK$LOG1:[LOGFILES], - DISK$LOG2:[LOGFILES] $ !

Create the transaction logs:

$ RUN SYS$SYSTEM:LMCP LMCP> CREATE LOG/SIZE=5000 DISK$LOG1:[LOGFILES]SYSTEM$BLUE.LM$JOURNAL LMCP> CREATE LOG DISK$LOG2:[LOGFILES]SYSTEM$RED.LM$JOURNAL LMCP> EXIT

Make sure DECdtm services are enabled:

$ SHOW LOGICAL SYS$DECDTM_INHIBIT %SHOW-S-NOTRAN, no translation for logical name SYS$DECDTM_INHIBIT

SYS$DECDTM_INHIBIT is undefined, so DECdtm services are enabled.

27.5 Monitoring Transaction Performance

Changes to your system, such as increase in work load, can affect transaction performance. Once a month, monitor transactions on the node to make sure that transaction performance has not deteriorated. In an OpenVMS Cluster environment, monitor transaction performance on all the nodes in the cluster.

How to Perform This Task

1. Monitor transactions, using the MONITOR TRANSACTION command:

   MONITOR TRANSACTION/SUMMARY[=file-spec]/ENDING=time/NODE=(nodename,...)

   where:

   file-spec	is the file specification of the summary file. Information about transactions is summarized and recorded in the summary file. If you omit the file specification, the information is recorded in MONITOR.SUM in your default directory.
   time	is the time that the monitoring session ends.
   nodename	is the name of a node. In an OpenVMS Cluster, list all the nodes in the cluster.

   
   For the best results, monitor transactions for a day at a time.
   You can monitor transactions in batch mode by including the MONITOR TRANSACTION command in a command procedure.
   For a full description of the MONITOR TRANSACTION command, refer to the OpenVMS System Management Utilities Reference Manual.

2. Examine the summary file.
   The summary file contains values for a number of different data items. Note the following values for each node:
   • Average end rate. This is the average number of transactions completed per second.
   • Average completion rates. These are the average numbers of transactions completed in the following times:

     Less than 1 second
     Between 1 and 2 seconds
     Between 2 and 3 seconds
     Between 3 and 4 seconds
     Between 4 and 5 seconds
     More than 5 seconds

   
   Keep a note of these values.
3. Compare the results from this monitoring session with the results from previous sessions.
   For the same work load, the rate and duration of transactions should remain about the same. Indications of performance deterioration are:
   • The average end rate decreases
   • The average duration increases
     To find out whether the average duration of transactions has increased, compare the average completion rates. If a greater proportion of the transactions takes longer to complete, the average duration of transactions has increased.
   
   Note any trends over a number of monitoring sessions. Variations from one monitoring session to the next are probably due to variations in work load.
   If you suspect that transaction performance has deteriorated on any node, check whether its transaction log is too small (see Section 27.6).
   If the transaction log is big enough, but transaction performance still deteriorates, tuning the system might be necessary. Refer to the OpenVMS Performance Management for information about tuning your system.

Example

This example shows how to monitor transaction performance on an OpenVMS Cluster that consists of two nodes whose SCSNODE names are BLUE and RED.

Monitor transactions on nodes BLUE and RED for one day:

$ MONITOR TRANSACTION/SUMMARY=DISK$LOG1:[LOGFILES]TRANSACTIONS.SUM - _$ /ENDING="+1-"/NODE=(BLUE,RED)

Examine the summary file:

DISTRIBUTED TRANSACTION STATISTICS on node BLUE From: 16-OCT-2000 14:23:51 SUMMARY To: 17-OCT-2000 14:23:51 CUR AVE MIN MAX Start Rate 49.02 43.21 31.30 49.02 Prepare Rate 48.70 43.23 30.67 48.70 One Phase Commit Rate 0.00 0.00 0.00 0.00 Total Commit Rate 48.70 43.19 31.30 48.70 Abort Rate 0.00 0.00 0.00 0.00 End Rate 48.70 43.19 31.30 48.70 Remote Start Rate 0.00 0.00 0.00 0.00 Remote Add Rate 0.00 0.00 0.00 0.00 Completion Rate 0-1 21.42 13.57 0.63 21.42 by Duration 1-2 25.97 29.15 24.59 33.87 in Seconds 2-3 1.29 0.47 0.00 4.47 3-4 0.00 0.00 0.00 0.00 4-5 0.00 0.00 0.00 0.00 5+ 0.00 0.00 0.00 0.00 SUMMARIZING DISTRIBUTED TRANSACTION STATISTICS on node RED From: 16-OCT-2000 14:23:52 SUMMARY To: 17-OCT-2000 14:23:52 . . .

Make a note of the following values:

• Average end rate.
  For node BLUE, the average end rate is 43.19 transactions per second.
• Average completion rates.
  For node BLUE, the average completion rates are as follows:

  13.57 transactions completed in 0 to 1 seconds
  29.15 transactions completed in 1 to 2 seconds
  0.47 transactions completed in 2 to 3 seconds

Compare the results from this monitoring session to those of previous sessions:

Session	End Rate	Completion Rates
		0--1 Secs	1--2 Secs	2--3 Secs
June	42.13	12.98	28.13	1.02
July	38.16	10.35	25.80	2.01
August	43.19	13.57	29.15	0.47

The results for node BLUE show no signs of deteriorating performance.

	privacy and legal statement
6017PRO_105.HTML