Administration Guide

Using the DB2MSCS Utility

You use the DB2MSCS utility to create the infrastructure for DB2 to support failover on the Windows NT environment using MSCS support. You can use this utility to enable failover in both single-partition and partitioned database environments.

You run the DB2MSCS utility once for each instance on its instance-owning machine. If there is only one DB2 instance running on one machine in the MSCS cluster, this sets up a hot-standby configuration. If you have an instance running on each machine in the MSCS cluster, you would run DB2MSCS once on each instance-owing machine to set up a mutual takeover configuration.

The DB2MSCS utility performs the following steps:

Reads the required MSCS and DB2 parameters from an input file called DB2MSCS.CFG. See "Specifying the DB2MSCS.CFG File" for information about the full set of input parameters.
Validates the parameters in the input file.
Registers the DB2 resource type.
Creates the MSCS group (or groups) to contain the MSCS and DB2 resources.
Creates the IP resource.
Creates the Network Name resource.
Moves MSCS disks to the group.
Creates the DB2 resource (or resources).
Adds all required dependencies for the DB2 resource.
Converts the non-clustered DB2 instance into a clustered instance.
Brings all resources online.

The syntax of the DB2MSCS utility is as follows:

>>-DB2MSCS---+------------------+------------------------------><
             '--f:--input_file--'

Where:

-f:input_file: Specifies the DB2MSCS.CFG input file to be used by the MSCS utility. If this parameter is not specified, the DB2MSCS utility reads the DB2MSCS.CFG file that is in the current directory.

Specifying the DB2MSCS.CFG File

The DB2MSCS.CFG file is an ASCII text file that contains parameters that are read by the DB2MSCS utility. You specify each input parameter on separate line using the following format: PARAMETER_KEYWORD=parameter_value. For example:

   CLUSTER_NAME=WOLFPACK
   GROUP_NAME=DB2 Group
   IP_ADDRESS=9.21.22.89

Two example configuration files are in the /CFG subdirectory of the /SQLLIB directory. The first, DB2MSCS.EE, is an example for single-partition database environments. The second, DB2MSCS.EEE, is an example for partitioned database environments.

The parameters for the DB2MSCS.CFG file are as follows:

DB2_INSTANCE

The name of the DB2 instance. If the instance name is not specified, the default instance (the value of the DB2INSTANCE environment variable) is used.

This parameter has a global scope, and you specify it only once in the DB2MSCS.CFG file.

This parameter is optional.

Example:

   DB2_INSTANCE=DB2

The instance must already exist. For information about creating instances, refer to the DB2 Extended Enterprise Edition for Windows NT Quick Beginnings.

DB2_LOGON_USERNAME

The name of the logon account for the DB2 service.

This parameter has a global scope, and you specify it only once in the DB2MSCS.CFG file.

This parameter is only required for DB2 Extended Enterprise Edition instances.

Example:

   DB2_LOGON_USERNAME=db2user

DB2_LOGON_PASSWORD

The password of the logon account for the DB2 service. If the DB2_LOGON_USERNAME parameter is provided but the DB2_LOGON_PASSWORD parameter is not, the DB2MSCS utility prompts for the password. The password is not displayed when it is typed at the command line.

This parameter has a global scope, and you specify it only once in the DB2MSCS.CFG file.

This parameter is only required for DB2 Extended Enterprise Edition instances.

Example:

   DB2_LOGON_PASSWORD=xxxxxx

CLUSTER_NAME

The name of the MSCS cluster. All the resources specified following this line are created in this cluster until another CLUSTER_NAME tag is specified.

Specify this parameter once for each cluster.

This parameter is optional. If not specified, the name of the MSCS cluster on the local machine is used.

Example:

   CLUSTER_NAME=WOLFPACK

GROUP_NAME

The name of the MSCS group. If this parameter is specified, a new MSCS group is created if it does not exist. If the group already exists, it is used as the target group. Any MSCS resource created following this line is created in this group until another GROUP_NAME keyword is specified.

Specify this parameter once for each group.

This parameter is required.

Example:

   GROUP_NAME=DB2 Group

DB2_NODE

The node number of the database partition server (node) to be included in the current MSCS group. If multiple logical nodes exist on the same machine, each node requires a separate DB2_NODE keyword.

You specify this parameter after the GROUP_NAME parameter so that the DB2 resources are created in the correct MSCS group.

This parameter is only required for DB2 Extended Enterprise Edition instances.

Example:

   DB2_NODE=0

IP_NAME

The name of the IP Address resource. The value for IP_NAME is arbitrary, but must be unique. When this parameter is specified, an MSCS resource of type IP Address is created.

This parameter is required for remote TCP/IP connections. You must specify this parameter for the instance-owning machine in a partitioned database enviroment. This parameter is optional in single-partition database environments.

Example:

   IP_NAME=IP Address for DB2

Note:

DB2 clients should use the TCP/IP address of this IP resource to catalog the TCP/IP node entry. By using the MSCS IP address, when the database server fails over to the other machine, DB2 clients can still connect to the database server because the IP address is available on the fail-over machine.

The attributes of the IP resource are as follows:

IP_ADDRESS

The TCP/IP address of the IP resource. Specify this keyword to set the TCP/IP address for the preceeding IP resource.

This parameter is required if the IP_NAME parameter is specified.

Example:

   IP_ADDRESS=9.21.22.34

IP_SUBNET

The subnet mask for the preceeding IP resource.

This parameter is required if the IP_NAME parameter is specified.

Example:

   IP_SUBNET=255.255.255.0

IP_NETWORK

The name of the MSCS network that the preceeding IP resource belongs to. If this parameter is not specified, the first MSCS network detected by the system is used.

This parameter is optional.

Example:

   IP_NETWORK=Token Ring

NETNAME_NAME

The name of the Network Name resource. Specify this parameter to create the Network Name resource.

This parameter is optional for single-partition database environments. It is required for partitioned database enviroments.

Example:

   NETNAME_NAME=Network name for DB2

The attributes of the Network Name resource are as follows:

NETNAME_VALUE

The value for the Network Name.

This parameter is required if NETNAME_NAME parameter is specified.

Example:

   NETNAME_VALUE=DB2SRV

NETNAME_DEPENDENCY

The dependency list for the Network Name resource. Each Network Name resource must have a dependency on an IP Address resource. If this parameter is not specified, the Network Name resource has a dependency on the first IP resource in the group.

This parameter is optional.

Example:

   NETNAME_DEPENDENCY=IP Address for DB2

DISK_NAME

The name of the physical disk resources to be moved to the current groups. Specify as many disk resources as you need.

Notes:

The disk resources must already exist.
When the DB2MSCS utility configures the DB2 instance for MSCS support, the instance directory is copied to the first MSCS disk in the group. To specify a different MSCS disk for the instance directory, use the INSTPROF_DISK parameter.

Example:

   DISK_NAME=Disk E:
   DISK_NAME=Disk F:

INSTPROF_DISK

An optional parameter to specify an MSCS disk to contain the DB2 instance directory. If this parameter is NOT specified, the DB2MSCS utility uses the first MSCS disk that belongs to the same group as the instance directory.

The DB2 instance directory is created on the MSCS disk under the X:\DB2PROFS directory (where X is the MSCS disk drive letter).

Example:

   INSTPROF_DISK=Disk E:

Setting up Failover for a Single-Partition Database System

When you run the DB2MSCS utility against a single-partition database system, one MSCS group contains DB2 and all the dependent MSCS resources (the IP address, Network Name, and disks). For example, the contents of the DB2MSCS.CFG for a single-partition database system will look like the following:

   #
   #  DB2MSCS.CFG for a single-partition database system
   #
   DB2_INSTANCE=DB2
   CLUSTER_NAME=MSCS
   GROUP_NAME=DB2 Group
   IP_NAME=...
   IP_ADDRESS=...
   IP_SUBNET=...
   IP_NETWORK=...
   NETNAME_NAME=...
   NETNAME_VALUE=...
   DISK_NAME=Disk E:

Setting up a Mutual Takeover Configuration for Two Single-Partition Database Systems

You can set up two single-partition database systems, each on a separate machine, so that if the database system on any one machine fails, it is restarted on the other MSCS node.

To setup failover support for this configuration, you need to run the DB2MSCS utility once on each instance-owning machine. You must tailor the configuration file for each database system.

Assume that the DB2 instances are called DB2A and DB2B. The DB2MSCS.CFG file for the DB2A instance would be as follows:

   #
   #  DB2MSCS.CFG for first single-partition database system
   #
   DB2_INSTANCE=DB2A
   CLUSTER_NAME=MSCS
   GROUP_NAME=DB2A Group
   IP_NAME=...
   IP_ADDRESS=...
   IP_SUBNET=...
   IP_NETWORK=...
   NETNAME_NAME=...
   NETNAME_VALUE=...
   DISK_NAME=Disk E:

The DB2MSCS.CFG file for the DB2A instance would be as follows:

   #
   #  DB2MSCS.CFG for second single-partition database system
   #
   DB2_INSTANCE=DB2B
   CLUSTER_NAME=MSCS
   GROUP_NAME=DB2B Group
   IP_NAME=...
   IP_ADDRESS=...
   IP_SUBNET=...
   IP_NETWORK=...
   NETNAME_NAME=...
   NETNAME_VALUE=...
   DISK_NAME=Disk F:

For a full example, see "Example - Setting up Two Single-Partition Instances for Mutual Takeover".

Setting up Multiple MSCS Clusters for a Partitioned Database System

When you run the DB2MSCS utility against a multipartition database system, one MSCS group is created for each physical machine that participates in the system. The DB2MSCS.CFG file must contain multiple sections, and each section must have a different value for the GROUP_NAME parameter and for all the required dependent resources for that group.

In addition, you must specify the DB2_NODE parameter for each database partition server in each MSCS group. If you have multiple logical nodes, each logical node requires a separate DB2_NODE keyword.

For example, assume that you have a multipartition database system that consists of four database partition servers on four machines, and you want to configure two MSCS clusters using mutual takeover configuration. You would set up the DB2MSCS.CFG configuration file as follows:

   #
   #  DB2MSCS.CFG for one partitioned database system with
   #  multiple clusters
   DB2_INSTANCE=DB2MPP
   DB2_LOGON_USERNAME=db2user
   DB2_LOGON_PASSWORD=xxxxxx
   CLUSTER_NAME=MSCS1
     # Group 1
   GROUP_NAME=DB2 Group 1
   DB2_NODE=0
   IP_NAME=...
   ...
   # Group 2
   GROUP_NAME=DB2 Group 2
   DB2_NODE=1
   IP_NAME=...
   ...
   CLUSTER_NAME=MSCS2
   # Group 3
   GROUP_NAME=DB2 Group 3
   DB2_NODE=2
   IP_NAME=...
   ...
   # Group 4
   GROUP_NAME=DB2 Group 4
   DB2_NODE=3
   IP_NAME=...
   ...

For a full example, see "Example - Setting up a Four-Node Partitioned Database System for Mutual Takeover".

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]