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 the PREVIOUS 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.
- DB2COMM
-
- DB2FCMCOMM
-
- 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
-
- 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
-
- 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
-
- 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.