Communications variables
You use communication variables to help control the flow of data on Db2® network connections and within the Db2 environment itself. You can set communication variables to control default behaviors such as TCP/IP settings and communication manager activity.
- DB2_ALLOW_WLB_WITH_SEQUENCES
-
- Operating system: All
- Default=NO, Values: NO, YES
- This registry variable controls whether applications that access sequences are allowed to
participate in workload balancing.
When DB2_ALLOW_WLB_WITH_SEQUENCES is set to NO, applications that reference PREVIOUS VALUE or NEXT VALUE in an SQL sequence statement are prevented from participating in workload balancing.
When DB2_ALLOW_WLB_WITH_SEQUENCES is set to YES, applications that reference PREVIOUS VALUE or NEXT VALUE in an SQL sequence statement are not prevented from participating in workload balancing. Applications must generate the next sequence value with the
NEXT VALUE FOR sequence
expression in a transaction before it references the previous value of the sequence using thePREVIOUS VALUE FOR sequence
expression. Because the application can participate in workload balancing, each transaction might run in a new session or a different session. Accessing a previous sequence value in a transaction without first generating the next sequence value results in a SQL0845N error.Sequence considerations in a Db2 pureScale® environment:
In a Db2 pureScale environment, if you use the CACHE and NO ORDER options, multiple caches might be active simultaneously. Requests for the next value from different members might not result in the assignment of values in strict numeric order. For example, members DB2A and DB2B are using the same sequence. DB2A gets the cache values 1-20, while DB2B gets the cache values 21-40. If DB2A requested the next value first, then DB2B requested, and then DB2A requested again, the order of values assigned would be 1, 21, 2.
Using the ORDER or NO CACHE option ensures that the values assigned to a sequence shared by one or more applications across multiple members are in strict numeric order. If ORDER is specified, then NO CACHE is implied even if CACHE n is specified.
- DB2CHECKCLIENTINTERVAL
-
- Operating system: All, server only
- Default=100, Values: A numeric value that is greater than or equal to zero.
- This variable specifies the
frequency of TCP/IP client connection verifications during an active transaction. It permits early
detection of client termination, instead of waiting until after the completion of the query. If this
variable is set to 0, no verification is performed.
Lower values cause more frequent checks. As a guide, for low frequency, use 100; for medium frequency, use 50; for high frequency use 10. The value is measured in an internal Db2 metric. The values represent a linear scale, that is, increasing the value from 50 to 100 doubles the interval. Checking more frequently for client status while executing a database request lengthens the time taken to complete queries. If the Db2 workload is heavy (that is, it involves many internal requests), setting DB2CHECKCLIENTINTERVAL to a low value has a greater impact on performance than in a situation where the workload is light.
Note: If this variable is set to 0, this may lead to orphaned connections that may lead to transactions holding back the active log. This will result in applications failing with a log full (SQL0964N) error.
- DB2_DYNAMIC_SSL_LABEL
-
- Operating system: All
- Default: OFF
- Starting in Db2 11.1 MP4 FP5, this parameter is used to control whether the value of the SSL_SVR_LABEL DBM configuration parameter is configurable online. For more information, see SSL_SVR_LABEL.
- Changes to this variable do not take effect immediately by default. To have them take effect immediately, issue the db2set command with the -immediate parameter.
- DB2COMM
-
- Operating system: All, server only
- Default=NULL, Values: NPIPE, TCPIP, SSL
- This variable specifies the
communication managers that are started when the database manager is started. If this variable is
not set, no Db2
communications managers are started at the server. You can set this variable to any combination of
the values, separated by commas.Note: The value NPIPE is valid only in Windows operating systems.
- DB2FCMCOMM
-
- Operating system: All supported Db2 Enterprise Server Edition platforms
- Default=TCPIP4, Values: TCPIP4 or TCPIP6
- This variable specifies how the host names in the db2nodes.cfg file
are resolved. All host names are resolved as IPv4 or IPv6. If an
IP address instead of a host name is specified in db2nodes.cfg,
the form of the IP determines if IPv4 or IPv6 is used. If DB2FCMCOMM is
not set, its default setting of IPv4 means that only IPv4 hosts can
be started. Note: If the IP format resolved from the hostname specified in db2nodes.cfg, or the IP format directly specified in db2nodes.cfg does not match the setting of DB2FCMCOMM, db2start will fail.
- DB2_FORCE_NLS_CACHE
-
- Operating system: AIX®, HP_UX, Solaris
- Default=FALSE, Values: TRUE or FALSE
- This variable is used to eliminate the chance of lock contention in multi-threaded applications. When this registry variable is TRUE, the code page and territory code information is saved the first time a thread accesses it. From that point, the cached information is used for any other thread that requests this information. This eliminates lock contention and results in a performance benefit in certain situations. This setting should not be used if the application changes locale settings between connections. It is probably not needed in such a situation because multi-threaded applications typically do not change their locale settings because it is not thread safe to do so.
- DB2_PMODEL_SETTINGS
- Operating system: All
- Changes to this variable will take effect immediately for all future compiled SQL statements. There is no need to restart the instance or to issue the db2set command with the -immediate parameter.
- This registry variable controls a set of parameters that allow you to modify
the behavior of various aspects of the Db2 internal
infrastructure. Separate parameters with a semicolon, as in the following
example:
db2set DB2_PMODEL_SETTINGS=MLN_REMOTE_LISTENER:TRUE;ENHANCED_ROLLBACK:TRUE;SRVLST_EQUAL_WEIGHT:TRUE
- Parameters:
- ENHANCED_ROLLBACK
- Default: FALSE
- Values: TRUE, FALSE
- Use the ENHANCED_ROLLBACK parameter to improve rollback behavior for units of work on Db2 servers in partitioned database environments. If you set this option to TRUE, rollback requests for units of work are sent only to logical database partitions that participated in the transaction.
- MLN_REMOTE_LISTENER
- Default: FALSE
- Values: TRUE, FALSE
- Use the MLN_REMOTE_LISTENER parameter
to start a TCP/IP listener on each logical database partition. If
you set this option to TRUE, applications can connect
directly to each logical database partition instead of routing requests
through the database partition server that is assigned to logical
port 0.
If you set this option to TRUE, ensure that the additional TCP/IP listeners do not use ports that are required by other services.
- SRVLST_EQUAL_WEIGHT
- Default: FALSE
- Values: TRUE, FALSE
- Use the SRVLST_EQUAL_WEIGHT parameter if
you want non-zero member weights in the server list to always be identical,
thereby overriding the default behavior in which member weights are
computed based on load. Member weights as contained in the server
list are used by a remote client to distribute workload when workload
balancing (WLB) is enabled.
If you set this option to TRUE, WLB at the client translates into even workload distribution among members with no regard for the member load.
- DB2RSHCMD
-
- Operating system: UNIX, Linux®
- Default=rsh (remsh on HP-UX), Values are a full path name to rsh, remsh, or ssh
- By default, Db2 database system uses rsh as the communication protocol when starting remote database partitions and with the db2_all script to run utilities and commands on all database partitions. For example, setting this registry variable to the full path name for ssh causes Db2 database products to use ssh as the communication protocol for the requested running of the utilities and commands. It may also be set to the full path name of a script that invokes the remote command program with appropriate default parameters. This variable is only required for partitioned databases, or for single-partition environments where the db2start command is run from a different server than where the Db2 product was installed and for rsh or ssh dependant utilities that have the capability of starting, stopping or monitoring a Db2 instance, such as db2gcf. The instance owner must be able to use the specified remote shell program to log in from each Db2 database node to each other Db2 database node, without being prompted for any additional verification or authentication (that is, passwords or password phrases).
For detailed instructions on setting the DB2RSHCMD registry variable to use a ssh shell with Db2, see the white paper "Configure DB2 Universal Database for UNIX to use OpenSSH."
- DB2RSHTIMEOUT
-
- Operating system: UNIX, Linux
- Default=30 seconds, Values: 1 - 120
- This variable is only applicable if DB2RSHCMD is set to a non-null value.
This registry variable is used to control the timeout period that the Db2 database system will
wait for any remote command. After this timeout period, if no response is received, the assumption
is made that the remote database partition is not reachable and the operation has failed. Note: The time value given is not the time required to run the remote command, it is the time needed to authenticate the request.
- DB2SORCVBUF
-
- Operating system: All
- Default=65 536
- Specifies the value of TCP/IP receive buffers.
- DB2SOSNDBUF
-
- Operating system: All
- Default=65 536
- Specifies the value of TCP/IP send buffers.
- DB2TCP_CLIENT_CONTIMEOUT
-
- Operating system: All, client only
- Default=0 (no timeout), Values: 0 - 32 767 seconds
- The DB2TCP_CLIENT_CONTIMEOUT registry
variable specifies the number of seconds that a client must wait for
the completion on a TCP/IP connect operation. A database connect operation
via TCP/IP involves both connect() and recv() socket subroutines.
The database manager returns the -30081 selectForConnectTimeout error
if the connect() subroutine reaches the timeout, and the -30081
selectForRecvTimeout error if the recv() subroutine reaches
the timeout.
There is no timeout if the registry variable is not set or is set to 0.
Note: Operating systems also have a connection timeout value that may take effect prior to the timeout you set using DB2TCP_CLIENT_CONTIMEOUT. For example, AIX has a default tcp_keepinit=150 (in half seconds) that would terminate the connection after 75 seconds. - Changes to this variable will take effect immediately for all future compiled SQL statements. There is no need to restart the instance or to issue the db2set command with the -immediate parameter.
- DB2TCP_CLIENT_KEEPALIVE_TIMEOUT
-
- Operating system: AIX, HP-UX, Linux, Windows (client only)
- Default=15, Values: 0 - 32 767 seconds
- The
DB2TCP_CLIENT_KEEPALIVE_TIMEOUT registry variable represents the total amount
of time in seconds a socket can remain idle; and not respond to keepalive probes before it is
considered unresponsive. When a socket is considered unresponsive, it is terminated by Db2. It is the
client-side equivalent of DB2TCP_SERVER_KEEPALIVE_TIMEOUT.
When this variable is not set, the default setting of 15 seconds is used. When the KeepAliveTimeout keyword is set to 0, the keepalive setting that is set in the operating system takes effect. If set, this variable takes precedence over any keepAliveTimeout setting as specified in the db2dsdriver.cfg file.
Changes to this variable take effect immediately for all future TCP/IP connections and attachments to the server
- DB2TCP_CLIENT_RCVTIMEOUT
-
- Operating system: All, client only
- Default=0 (no timeout), Values: 0 - 32 767 seconds
- The DB2TCP_CLIENT_RCVTIMEOUT registry variable specifies the number of
seconds a client waits for data on a TCP/IP receive operation. If data from the server is not
received in the seconds specified, then the Db2 database manager
returns the error -30081 selectForRecvTimeout.
There is no timeout if the registry variable is not set or is set to 0.
Note: The value of the DB2TCP_CLIENT_RCVTIMEOUT can be overridden by the CLI, using the db2cli.ini keyword ReceiveTimeout or the connection attribute SQL_ATTR_RECEIVE_TIMEOUT. - Changes to this variable will take effect immediately for all future compiled SQL statements. There is no need to restart the instance or to issue the db2set command with the -immediate parameter.
- DB2TCPCONNMGRS
-
- Operating system: All
- Default=1 on serial machines; square root of the number of processors rounded up to a maximum of sixteen connection managers on symmetric multiprocessor machines. Values: 1 to 16
- The default number of connection managers is created if the registry
variable is not set. If the registry variable is set, the value assigned
here overrides the default value. The number of TCP/IP connection
managers specified up to a maximum of 16 is created.
If less than 1 is specified then DB2TCPCONNMGRS is
set to a value of 1 and a warning is logged that
the value is out of range. If greater than 16 is
specified then DB2TCPCONNMGRS is set to a value
of 16 and a warning is logged that the value is
out of range. Values between 1 and 16 are
used as given. When there is greater than one connection manager created,
connection throughput should improve when multiple client connections
are received simultaneously. There may be additional TCP/IP connection
manager processes (on UNIX)
or threads (on Windows operating
systems) if the user is running on a SMP machine, or has modified
the DB2TCPCONNMGRS registry variable. Additional
processes or threads require additional storage. Note: Having the number of connection managers set to 1 causes a drop in performance on remote connections in systems with a lot of users, frequent connects and disconnects, or both.
- DB2TCP_SERVER_KEEPALIVE_TIMEOUT
-
- Operating system: AIX, HP-UX, Linux, Windows (server only)
- Default=60, Values: 0 - 32 767 seconds
-
The DB2TCP_SERVER_KEEPALIVE_TIMEOUT registry variable specifies the maximum time in seconds before an unresponsive TCP/IP client connection or attachment is detected as no longer alive. It is the server-side equivalent of DB2TCP_CLIENT_KEEPALIVE_TIMEOUT and keepAliveTimeout. When this variable is not set, the default setting of 60 seconds is used.
Changes to this variable take effect immediately for all future TCP/IP connections and attachments to the server. There is no need to restart the server instance.