Format of the Db2 node configuration file
The db2nodes.cfg file is used to define the database partition servers that participate in a Db2 instance. The db2nodes.cfg file is also used to specify the IP address or host name of a high-speed interconnect, if you want to use a high-speed interconnect for database partition server communication.
dbpartitionnum, hostname, logicalport, netname, and resourcesetname are defined in the following section.
dbpartitionnum hostname logicalport netname resourcesetname
On Windows operating systems, these entries to the db2nodes.cfg are added by the db2ncrt or START DBM ADD DBPARTITIONNUM commands. The entries can also be modified by the db2nchg command. You should not add these lines directly or edit this file.
dbpartitionnum hostname computername logicalport netname resourcesetname
- A unique number, between 0 and 999, that identifies a database
partition server in a partitioned database system.
To scale your partitioned database system, you add an entry for each database partition server to the db2nodes.cfg file. The dbpartitionnum value that you select for additional database partition servers must be in ascending order, however, gaps can exist in this sequence. You can choose to put a gap between the dbpartitionnum values if you plan to add logical partition servers and want to keep the nodes logically grouped in this file.
This entry is required.
- The TCP/IP host name of the database partition server for use by the FCM. This entry is
required. Canonical hostname is strongly
When the system has more than one network interface card installed and the hostname that is used in the db2nodes.cfg file cannot be resolved to be the default host of the system, it might be treated as a remote host. This setup imposes a limitation that database migration cannot be done successfully because the local database directory cannot be found if the instance is not started. Therefore, HADR might require the hostname to match the name that is used by the operating system to identify the host to make migration possible. In addition to this, the operating system name of the host must be specified in db2nodes.cfg when it is running in a Tivoli® SA MP, PowerHA® SystemMirror®, and other high availability environments, including the Db2 fault monitor.
Starting with Db2 Version 9.1, both TCP/IPv4 and TCP/IPv6 protocols are supported. The method to resolve host names has changed.
While the method used in pre-Version 9.1 releases resolves the string as defined in the db2nodes.cfg file, the method in Version 9.1 or later tries to resolve the Fully Qualified Domain Names (FQDN) when short names are defined in the db2nodes.cfg file. Specifying short configured for fully qualified host names, this may lead to unnecessary delays in processes that resolve host names.To avoid any delays in Db2 commands that require host name resolution, use any of the following workarounds:
- If short names are specified in the db2nodes.cfg files and the operating system host name file, specify the short name and the fully qualified domain name for host name in the operating system host files.
- To use only IPv4 addresses when you know that the Db2 server listens on an
IPv4 port, issue the following command:
db2 catalog tcpip4 node db2tcp2 remote 22.214.171.124 server db2inst1 with "Look up IPv4 address from 126.96.36.199"
- To use only IPv6 addresses when you know that the Db2 server listens on an
IPv6 port, issue the following command:
db2 catalog tcpip6 node db2tcp3 1080:0:0:0:8:800:200C:417A server 50000 with "Look up IPv6 address from 1080:0:0:0:8:800:200C:417A"
- Specifies the logical port number for the database partition server. This field is used to
specify a particular database partition server on a workstation that is running logical database
Db2 reserves a port range (for example, 60000 - 60003) in the /etc/services file for interpartition communications at the time of installation. This logicalport field in db2nodes.cfg specifies which port in that range you want to assign to a particular logical partition server.
If there is no entry for this field, the default is 0. However, if you add an entry for the netname field, you must enter a number for the logicalport field.
If you are using logical database partitions, the logicalport value you specify must start at 0 and continue in ascending order (for example, 0,1,2).
Furthermore, if you specify a logicalport entry for one database partition server, you must specify a logicalport for each database partition server listed in your db2nodes.cfg file.
Each physical server must have a logical node 0.
This field is optional only if you are not using logical database partitions or a high speed interconnect.
- Specifies the host name or the IP address of the high speed interconnect
for FCM communication.
If an entry is specified for this field, all communication between database partition servers (except for communications as a result of the db2start, db2stop, and db2_all commands) is handled through the high speed interconnect.
This parameter is required only if you are using a high speed interconnect for database partition communications.
- The resourcesetname defines the operating system resource that the node
should be started in. The resourcesetname is for process affinity support, used
for Multiple Logical Nodes (MLNs). This support is provided with a string type field formerly known
This parameter is only supported on AIX®.
On AIX, this concept is known as "resource sets", refer to AIX documentation for more information about resource management.
On Windows operating systems, process affinity for a logical node can be defined through the DB2PROCESSORS registry variable.
On Linux operating systems, the resourcesetname column defines a number that corresponds to a Non-Uniform Memory Access (NUMA) node on the system. The system utility numactl must be available as well as a 2.6 Kernel with NUMA policy support.
The netname parameter must be specified if the resourcesetname parameter is used.
Use the following example configurations to determine the appropriate configuration for your environment.
- One computer, four database partitions servers
- If you are not using a clustered environment and want to have
four database partition servers on one physical workstation called
ServerA, update the db2nodes.cfg file as follows:
0 ServerA 0 1 ServerA 1 2 ServerA 2 3 ServerA 3
- Two computers, one database partition server per computer
- If you want your partitioned database system to contain two physical
ServerB, update the db2nodes.cfg file as follows:
0 ServerA 0 1 ServerB 0
- Two computers, three database partition server on one computer
- If you want your partitioned database system to contain two physical
ServerAis running 3 database partition servers, update the db2nodes.cfg file as follows:
4 ServerA 0 6 ServerA 1 8 ServerA 2 9 ServerB 0
- Two computers, three database partition servers with high speed switches
- If you want your partitioned database system to contain two computers,
ServerBrunning two database partition servers), and use a high speed interconnect called
switch2, update the db2nodes.cfg file as follows:
0 ServerA 0 switch1 1 ServerB 0 switch2 2 ServerB 1 switch2
Examples using resourcesetname
- This example shows the usage of resourcesetname when there is no high speed interconnect in the configuration.
- The netname is the fourth column and a hostname also can be specified on that column where there is no switch name and you want to use resourcesetname. The fifth parameter is resourcesetname if it is defined. The resource group specification can only show as the fifth column in the db2nodes.cfg file. This means that for you to specify a resource group, you must also enter a fourth column. The fourth column is intended for a high speed switch.
- If you do not have a high speed switch or you do not want to use it, you must then enter the hostname (same as the second column). In other words, the Db2 database management system does not support column gaps (or interchanging them) in the db2nodes.cfg files. This restriction already applies to the first three columns, and now it applies to all five columns.
Here is an example of how to set up the resource set for AIX operating systems.
In this example, there is one physical node with 32 processors and 8 logical database partitions (MLNs). This example shows how to provide process affinity to each MLN.
- Define resource sets by using the AIX mkrset command:
mkrset -c 0 1 2 3 DB2/MLN1 mkrset -c 4 5 6 7 DB2/MLN2 mkrset -c 8 9 10 11 DB2/MLN3 mkrset -c 12 13 14 15 DB2/MLN4 mkrset -c 16 17 18 19 DB2/MLN5 mkrset -c 20 21 22 23 DB2/MLN6 mkrset -c 24 25 26 27 DB2/MLN7 mkrset -c 28 29 30 31 DB2/MLN8
- Give instance permissions to use resource sets:
chuser capabilities= CAP_BYPASS_RAC_VMM,CAP_PROPAGATE,CAP_NUMA_ATTACH db2inst1
- Add the resource set name as the fifth column in db2nodes.cfg:
1 regatta 0 regatta DB2/MLN1 2 regatta 1 regatta DB2/MLN2 3 regatta 2 regatta DB2/MLN3 4 regatta 3 regatta DB2/MLN4 5 regatta 4 regatta DB2/MLN5 6 regatta 5 regatta DB2/MLN6 7 regatta 6 regatta DB2/MLN7 8 regatta 7 regatta DB2/MLN8
On Linux operating systems, the resourcesetname column defines a number that corresponds to a Non-Uniform Memory Access (NUMA) node on the system. The numactl system utility must be available in addition to a 2.6 kernel with NUMA policy support. Refer to the man page for numactl for more information about NUMA support on Linux operating systems.
This example shows how to set up a four node NUMA computer with each logical node associated with a NUMA node.
- Ensure that NUMA capabilities exist on your system.
- Issue the following command:
Output similar to the following displays:
$ numactl --hardware
available: 4 nodes (0-3) node 0 size: 1901 MB node 0 free: 1457 MB node 1 size: 1910 MB node 1 free: 1841 MB node 2 size: 1910 MB node 2 free: 1851 MB node 3 size: 1905 MB node 3 free: 1796 MB
- In this example, there are four NUMA nodes on the system. Edit
the db2nodes.cfg file as follows to associate
each MLN with a NUMA node on the system:
0 hostname 0 hostname 0 1 hostname 1 hostname 1 2 hostname 2 hostname 2 3 hostname 3 hostname 3