There are a number of places where we can store and change configuration for a Db2 server. I wanted to walk through the main areas and a few details about them.
Db2 Registry
The Db2 registry actually has a number of levels within itself. It is accessed using the db2set command. This is not the Windows registry. By default a couple of parameters are set at the global level in the Db2 registry when an instance is created. If db2set is run as an instance owner without specifying the level at which a setting should apply, then it takes effect at the instance level. The levels of the Db2 registry are:
- Operating system enviornment [e]
- Node level registry [n]
- Instance level registry [i]
- Global level registry [g]
Most of the parameters in the DB2 registry require a db2stop/db2start to take effect, but some may be able to take effect dynamically. To check whether a parameter can take effect without a recycle, use the -info <variable> option on the db2set command, like this:
> db2set -info DB2COMM Immediate change supported : NO Immediate by default : NO
Some Db2 registry parameters, like DB2_WORKLOAD, are aggregate parameters that include setting a number of other registry parameters. If any Db2 registry parameters are set by an aggregate parameter, they will have the name of that parameter in square brackets, like this:
[i] DB2_EVALUNCOMMITTED=YES [DB2_WORKLOAD]
Most registry variables are documented in the Db2 Knowledge Center, however IBM sometimes introduces new functionality with a hidden or undocumented registry variable. Unlike the other major configuration locations below, Db2 registry variables do not each have their own page in the Db2 Knowledge Center, and can be a bit frustrating to find at times.
Updating Values
The db2set command is used to update the values of Db2 registry parameters. The general syntax is:
db2set parameter=value
For example:
db2set DB2COMM=TCPIP
After changing a value, always verify that the change has taken effect.
Database Manager(DBM) Configuration
The database manager configuration consists of a large number of parameters that are set at the Db2 instance level.
Viewing Values
This configuration is often referred to as the “dbm cfg” because the shortest command for listing these variables and their values is:
db2 get dbm cfg
If you’re looking for just one parameter, it’s easiest to pipe the output to grep on Linux/UNIX or select-string at a PowerShell command line:
$ db2 get dbm cfg |grep INSTANCE_MEMORY Global instance memory (% or 4KB) (INSTANCE_MEMORY) = AUTOMATIC(187170)
PS C:\Windows\system32> db2 get dbm cfg |select-string instance_memory Global instance memory (% or 4KB) (INSTANCE_MEMORY) = AUTOMATIC(399591)
Some parameters, when changed, have the new value deferred until the next db2start. To see the deferred value, the show detail keywords are used on the get dbm cfg command. Using these keywords requires an instance attachment:
$ db2 attach to db2inst2 Instance Attachment Information Instance server = DB2/LINUXX8664 11.1.1.1 Authorization ID = DB2INST2 Local instance alias = DB2INST2 $ db2 get dbm cfg show detail |grep INSTANCE_MEMORY Global instance memory (% or 4KB) (INSTANCE_MEMORY) = AUTOMATIC(187170) AUTOMATIC(187170)
If the deferred value and the current value are the same, then no change will take place for the parameter on db2start.
In addition to using the get dbm cfg command, the values for the database manager configuration parameters can be queried using the SYSIBMADM.DBMCFG administrative view like this:
select substr(value,1,18) as value
, value_flags
, substr(deferred_value,1,18) as deferred_value
, deferred_value_flags
from SYSIBMADM.DBMCFG
where name='instance_memory'
VALUE VALUE_FLAGS DEFERRED_VALUE DEFERRED_VALUE_FLAGS
------------------ ----------- ------------------ --------------------
187170 AUTOMATIC 187170 AUTOMATIC
1 record(s) selected.
Querying the administrative view requires a database connection, while the get dbm cfg command doesn’t even require the Db2 instance be started.
Researching Parameters and Propagation Boundaries
Many of the parameters in the database manager configuration require a db2stop/db2start to take effect. Each parameter has an inidividual page in the IBM Db2 Knowledge Center. A list of all the parameters links to each individual page. While the summary list includes whether each parameter can be changed online, the individual page for the parameter also contains this information. If the parameter can be changed online, then the “Parameter type” section will say “Configurable Online”, and the “Propagation Class” section will specify when the change will take place. This is an example:
There is a wealth of other information on the parameter page for each parameter.
Updating Values
The db2 update dbm cfg command is used to update the values of dbm cfg parameters. The general syntax is:
db2 update dbm cfg using parameter value
For example:
db2 update dbm cfg using SYSMON_GROUP mon_grp
After changing a value, always verify that the change has taken effect using the show detail syntax detailed above. Sometimes if a parameter is deferred, you can attach to the instance and re-issue the update command to make the setting immediate. You may also want to use the immediate keyword:
db2 update dbm cfg using SYSMON_GROUP mon_grp immediate
Multiple changes can be done in a single command with syntax like this:
db2 update dbm cfg using parameter1 value1 parameter2 value2
For example:
db2 update dbm cfg using SYSMON_GROUP mon_grp mon_dft_buffpool ON
Database(DB) Configuration
There is a separate database configuration for each database, even if the databases are in the same instance. There are a lot of similarities between the db config and the dbm config. In fact, over the years, it seems like some things that used to be set at the database manager level seem to move to the database level. For example, the old snapshot monitors used the DFT_MON parameters in the dbm configuration. The newer mon_get* interfaces use the MON_* variables in the db configuration.
Viewing Values
The command for viewing the database configuration is similar to the one for the dbm cfg, though if there is no database connection, the database name must be specified:
db2 get db cfg for sample
Again, If you’re looking for just one parameter, it’s easiest to pipe the output to grep on Linux/UNIX or select-string at a PowerShell command line:
$ db2 get db cfg for sample |grep DATABASE_MEMORY Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC(63936)
PS C:\Windows\system32> db2 get db cfg for sample |select-string database_memory Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC(62336)
Some parameters, when changed, have the new value deferred until the next database deactivation and activation. To see the deferred value, the show detail keywords are used on the get db cfg command. Using these keywords requires an database connection:
$ db2 connect to sample Database Connection Information Database server = DB2/LINUXX8664 11.1.1.1 SQL authorization ID = DB2INST2 Local database alias = SAMPLE $ db2 get db cfg for sample show detail |grep DATABASE_MEMORY Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC(63936) AUTOMATIC(63936)
If the deferred value and the current value are the same, then no change will take place for the parameter on database deactivation/activation.
In addition to using the get db cfg command, the values for database configuration parameters can be queried using the SYSIBMADM.DBCFG administrative view like this:
select substr(value,1,18) as value
, value_flags
, substr(deferred_value,1,18) as deferred_value
, deferred_value_flags
from SYSIBMADM.DBCFG
where name='database_memory'
VALUE VALUE_FLAGS DEFERRED_VALUE DEFERRED_VALUE_FLAGS
------------------ ----------- ------------------ --------------------
63936 AUTOMATIC 63936 AUTOMATIC
1 record(s) selected.
Querying the administrative view requires a database connection, while the get db cfg command doesn’t.
Researching Parameters and Propagation Boundaries
Some of the parameters in the database configuration require the database be deactivated and then activated (while there are no connections) to take effect. Each parameter has an individual page in the IBM Db2 Knowledge Center. A list of all the parameters links to each individual page. While the summary list includes whether each parameter can be changed online, the individual page for the parameter also contains this information. If the parameter can be changed online, then the “Parameter type” section will say “Configurable Online”, and the “Propagation Class” section will specify when the change will take place. This is an example:
There is a wealth of other information on the parameter page for each parameter.
Updating Values
The db2 update db cfg command is used to update the values of db cfg parameters. The general syntax is:
db2 update db cfg for dbname using parameter value
For example:
db2 update db cfg for sample using LOCKTIMEOUT 90
After changing a value, always verify that the change has taken effect using the show detail syntax detailed above. Sometimes if a parameter is deferred, you can connect to the database and re-issue the update command to make the setting immediate. You may also want to use the immediate keyword:
db2 update db cfg for sample using LOCKTIMEOUT 90 immediate
Multiple changes can be done in a single command with syntax like this:
db2 update db cfg for dbname using parameter1 value1 parameter2 value2
For example:
db2 update db cfg using LOCKTIMEOUT 90 NEWLOGPATH /db2logs
Note that some parameters may put the database into a backup pending state, so be sure to research parameters before changing them.
Other Configurations
There are a wealth of other locations where things can be configured. Some parameters can be set in the userprofile (which is sourced by the db2profile). Others can be set in the CLI configuration file for certain kinds of applications. Some are set for the current session only, and the methodology for setting them depends heavily on the type of application being used. If the same parameter can be set in multiple places, the local or session values usually override the ones set at the server level. An example of this is LOCKTIMEOUT. There is always some value set for this at the database level in the db cfg. However, it can also be configured at the session/connection level using the SET CURRENT LOCK TIMEOUT command. It can also be set using an ODBC keyword. Things like binding packages can also have a profound impact on how a database behaves.
