Everything You Wanted to Know About DB2 Universal Database Processes


© 2003 International Business Machines Corporation. All rights reserved.

This article was written for IBM® DB2® Universal DatabaseTM v8.1 for Linux, UNIX®, and Windows®

UNIX and Linux users commonly examine the processes that are running on their servers to perform problem analysis as well as to examine the resources being consumed within the server. This information is useful not only to administrators who are performing problem and resource analysis, but also to those developing high availability and failover scripts that monitor the DB2 processes to determine when an action such as a database restart or server failover is needed.

Using AIX, you would use the command ps -ef in order to examine processes. On Solaris and HP-UX, ps -ef will only show the db2sysc process (the main DB2 engine process) for all server-side processes (eg: agents, loggers, page cleaners, and prefetchers). If you're using Solaris or HP-UX, you can see these side processes with the command /usr/ucb/ps -axw. Both of these versions of the ps command work on Linux.

When performing this command on a computer running the DB2 Universal Database client or server software, you may see several DB2 processes listed. The purpose of this article is to document these processes and explain what they do and when they may run. Although the most important processes are documented in Chapter 2 of the manual DB2 UDB V8 Administration Guide - Performance, the list is not complete. By reading this article you will be able to understand each of the DB2 processes, and you can begin to see what actions DB2 is performing when you see those processes.

Note that the implementation of how work is performed in DB2 is somewhat different on Windows than Linux and UNIX-based environments. In Windows, there is only one process (db2sysc) under which each of the engine dispatchable units (EDUs) is implemented as a thread. Though the article discusses processes, they should be thought of as threads in the Windows environment. From the Windows Task Manager you will be able to see the db2sysc process (db2syscs.exe) for each instance. Other Windows services/processes will also be displayed, and we will explain what they are in this article.

Warning! Do not meddle directly with the DB2 processes in a healthy DB2 environment. Killing a DB2 process with the kill -9 command in Linux or UNIX may cause undesirable behaviors in DB2. Killing the db2sysc process, for example, will bring the entire DB2 instance down. The idea here is to gain understanding of the processes but not to manipulate them directly.

Why look at DB2 processes?

Our personal experiences have shown the value of this knowledge, and the customers we have visited have asked us for this type of information. Not yet convinced? Take a look at the following real-life scenarios, and see for yourself how problems were resolved by reviewing the DB2 processes running on a system:

Scenario 1: Infrequent cleaning of buffer pool pages

A customer running an eCommerce site and using DB2 as the database server reported that at various times throughout the day, the database response time for application requests would become very long. Database snapshots did not show anything abnormal occurring at these times. By examining the CPU usage of the processes on the server at one of these times we were able to determine that the I/O cleaners (db2pclnr) were consuming over 90% of the CPU time. By subsequently looking at the I/O cleaner triggers and tuning them appropriately, we eliminated this condition and the eCommerce site was able to handle over 50% higher throughput on a daily basis.

Scenario 2: The truth comes out

While visiting an IBM business partner to perform some DB2 performance tuning, we encountered a general slowdown in query response time. A list applications command didn't show anything out of the ordinary running at the time. Before taking DB2 snapshots, we took a look at the DB2 processes running on the DB2 server and found that the db2rebal process was running. This process is used to perform a rebalancing of the data when a container is added to a DMS table space. The customer "confessed" that earlier that day he had added one container to a tablespace containing a 40 GB table. Once the rebalancing finished, the queries returned to their original response times.

Shedding some light on the notification and diagnostic logs

The administration notification log and the diagnostic log (db2diag.log) are important tools that administrators use to understand database activities and functions. These normally contain information about DB2 processes as shown in the example below taken from a db2diag.log entry:

2000-03-06-    Instance:myInst   Node:000  
PID:78121(db2agent (TEST)) TID:352    
lock_manager          sqlplrq    Probe:111   Database:TEST  
DIA9999E  An internal return code occurred. Report the following: 

In this example, the message came from process ID number 78121. The name of this process is db2agent and it is connected to the database named TEST. Understanding what a process does can help you make sense of the entries in the administration notification log and db2diag.log.

The DB2 process model

Although the DB2 process model is explained in the DB2 Administration Guide - Performance manual, we will give you a brief overview here. We'll first describe the concept of an agent.


An agent can be thought of as a 'worker' that performs all database operations on behalf of an application. There are two main types of DB2 agents:

  • Coordinator Agent (db2agent)
    A coordinator agent (or a coordinating agent) coordinates the work on behalf of an application and communicates to other agents using interprocess communication (IPC) or remote communication protocols. All connection requests from client applications, whether they are local or remote, are allocated a corresponding coordinator agent.
  • Subagent (db2agntp)
    When the intra_parallel database manager configuration parameter is enabled, the coordinator agent distributes the database requests to subagents (db2agntp). These agents perform the requests for the application. Once the coordinator agent is created, it handles all database requests on behalf of its application by coordinating subagents (db2agent) that perform requests on the database.

When an agent or subagent completes its work it becomes idle. When a subagent becomes idle, its name changes from db2agntp to db2agnta.

For example:

db2agntp processes are active subagents which are currently performing work for the coordinator agent. These processes will only exist when intra-partition parallelism is enabled.

db2agnta processes are idle subagents that were used in the past by a coordinator agent.

Idle agents reside in an agent pool. These agents are available for requests from coordinator agents operating on behalf of client programs, or from subagents operating on behalf of existing coordinator agents. The number of available agents is dependent on the database manager configuration parameters maxagents and num_poolagents.

We'll describe other types of agents like the parallel recovery agent (db2agnsc) later in the article.

The following two figures show the DB2 Process model.

Figure 1. The DB2 process model without connection concentration (for a non-partitioned database)
Figure 1
Figure 1

Each of the circles in Figure 1 represent engine dispatchable units (EDUs) which are known as processes on Linux/UNIX platforms, and threads on Windows .

Applications A (App A) and B (App B) are local applications running in the same machine where the DB2 server resides. When these applications issue a CONNECT to a database, the db2ipccm listener process establishes the communication between the database manager and the application. db2ipccm will also work with a coordinator agent EDU (db2agent) which contacts the client application directly to establish shared memory communications between the client application and the coordinator. Once this communication is established, the application at the local client is connected to the database.

Application C (App C) is a remote application residing in a machine different than the one used for the DB2 Server. A remote client establishes TCP/IP communications through the db2tcpcm listener process. The db2tcpcm then works with a db2agent, which becomes the coordinator agent for the application and passes the connection to this agent. After this, the coordinator agent contacts the remote client application and is connected to the database.

Figure 2. The DB2 process model without connection concentration for a partitioned database
Figure 2
Figure 2

Figure 2 is similar to Figure 1, but is applicable to partitioned databases. Node0000 and Node0001 represent two different machines where part of a database resides. The processes and interaction between them is the same as described in Figure 1; however, there are some other processes applicable only to this environment. The db2fcmd process for example is the Fast Communication Manager process used to manage the communication between the different partitions. The table in the next section will describe in more detail other processes applicable to partitioned databases.

The processes

The following tables lists all the DB2 processes per instance, per database, and by function. Note that some of the processes in the tables below are not listed in alphabetical order, but grouped based on functionality. If you would like to look for a process in alphabetical order, refer to Table 7 below.

Table 1. Per instance processes - no connections, no active databases

db2cartDetermines when a log file can be archived and invokes the user exit to do the actual archiving. There is one db2cart process per instance, but it is only running if there is at least one database in the instance which has USEREXIT enabled.All
db2chkauUsed by the DB2 audit facility to log entries to the Audit log. It is only active if auditing has been enabled.All
db2ckpwUsed to check the user id and password on the DB2 server. Since DB2 relies on operating system level authentication, this process is used to verify the user id and password when a user or application connects to a database on the server. Authentication will occur when AUTHENTICATION is set to SERVER, or when a connection is made from a non-secure operating system.UNIX/Linux
db2dispThe DB2 agent dispatcher process. This process dispatches application connections between the logical agent assigned to the application and the available coordinating agents when connection concentration is enabled.

This process will only exist when connection concentration is enabled.

db2fcmdFCM (Fast Communication Manager) daemon for handling inter-partition communications. One per server, per partition.Multi-partitioned database environment only
db2fmcdThe Fault Monitor Coordinator daemon process. One per physical machine.UNIX only
db2fmdThe fault monitor daemon process that is started for every instance of DB2 that is monitored by the fault monitor. It is monitored by the coordinator daemon (db2fmcd), so if you kill the db2fmd process, db2fmcd will bring it back up.UNIX only
db2fmtlgPre-allocates log files in the log path when the database is configured with LOGRETAIN ON and USEREXIT OFF. This is done so the engine process does not need to wait while switching from one log file to the next during normal processing.All
db2gdsThe DB2 Global Daemon Spawner process that starts all DB2 EDUs (processes) on UNIX. There is one db2gds per instance or database partition.UNIX only
db2glockGlobal deadlock detector. This coordinates the information gathered from the db2dlock process on each database partition to check for deadlock conditions that exist between database partitions. The db2glock process runs on the catalog partition of a multi-partitioned database.Multi-partitioned database environment only
db2govdThe DB2 Governor, a reactive governoring process. If DB2 governor is enabled, this process takes snapshots at the interval specified in the governor configuration file and checks the snapshot against all configured rules. If a rule is broken, the specified action is taken.All
db2panicThe panic agent. It handles urgent requests after agent limits have been reached on any of the database's partitions.Multi-partitioned database environment only
db2pdbcThe PDB (Parallel Database) Controller. It handles parallel requests from remote nodes.Multi-partitioned database environment only
db2rebalThe rebalancer process. It is called when containers are added to an existing table space and a rebalance of the existing data is required. This process performs the rebalance asynchronously.All
db2resynThe resync manager process used to support applications that are using two-phase commitAll
db2srvlstProcess used to manage lists of addresses for systems such as OS/390.All
db2syscThe main DB2 system controller or engine. Without this process, the database server cannot function.All
db2syslogThe system logger process. This process writes to the operating system error log facility. On UNIX this must be enabled by editing the file syslog.conf. On Windows DB2 will automatically write the Windows event log.All
db2wdogThe DB2 watchdog. This process is required since processes in UNIX can only track their parent process ID. Each time a new process is started, the db2gds notifies the DB2 watchdog. In the event that any DB2 process receive a ctrl-c or other abnormal signal, the process send the signal to the watchdog, and it propagates the signal to all of the other processes in the instance.UNIX only
dlasyncA monitor for the DB2 Data Links (File Manager) servers. This process only exists if DB2 has been configured for data links.Data Links only

Table 2. Per instance and per connection

db2agentDB2 coordinator/coordinating agent which performs all database requests on behalf of an application. There will be one db2agent process per connected application, unless the connection concentrator is enabled.

If intra-partition parallelism is enabled, the db2agent process will call the DB2 subagents to perform the work, and they will return the result set to the coordinator agent to return to the applicaiton.

In a partitioned database, the coordinator agent will exist on the partition which the application connected to.
db2agentgThe gateway agent for DRDA Application Requesters.All
db2agnscThe parallel recovery agent. This agent is used during roll forward and restart recovery to perform the actions from the logs in parallel. This can improve recovery time in comparison to a serial recovery.

Note: This process enables parallelism within logged transactions, as well as between parallel transactions.
db2agntaAn idle subagent that was used in the past by a coordinating agent and is still associated to that coordinating agent process.

It will appear when the INTRA_PARALLEL dbm cfg parameter is set to YES.
db2agntpA subagent that is currently performing work on behalf of the coordinating agent it is associated with. These processes provide intra-partition parallelism, i.e. the ability to execute a query in parallel within a database instance / partition

It will apprear when the INTRA_PARALLEL dbm cfg parameter is set to YES.
db2ipccmIPC communication manager. One per database partition. This is the interprocess communication listener for local client connections.

A local client connection is a connection made from an application (such as the CLP) within the same computer where the DB2 server is running.
db2tcpcmTCP communication manager. It works as a communication listener for TCP/IP connection requests. When a connection request is received, the listener associates the connection with an agent, and then resumes listening for more connection requests.All
db2tcpdmCommunication listener for TCP/IP discovery requests. Discovery requests are made by the configuration assistant (CA) when it is searching the network for remote DB2 servers and their databases.All
db2snacmSNA / APPC Communication manager. It works as a communication listener for SNA/APPC connection requests. When a connection request is received, the listener associates the connection with an agent, and then resumes listening for more connection requests.All

Table 3. Per instance and per active database

db2dlockLocal deadlock detector, one per database partition. It scans the lock list and looks for deadlock conditions. When a deadlock condition is encountered, one of the applications / transactions involved is chosen as the victim and rolled back.All
db2estorUsed to copy pages between the database buffer pools and extended storage. These processes will appear only when extended storage is enabled for a database.All
db2eventThe event monitor process. There will be one db2event process per active event monitor, per active database. These processes capture the defined "events" and write to the output file specified for the event monitor.All
db2loggrThe database log reader. This process reads the database log files during:
  • transaction processing (i.e. rollback)
  • restart recovery
  • rollforward operations
db2loggwThe database log writer. This process flushes log records from the log buffer to the log files on disk.All
db2logtsProcess used for collecting historical information about which logs are active when a table space is modified. This information is recorded in the DB2TSCHG.HIS file in the database directory. It is used to speed up table space rollforward recovery by enabling the skipping of log files that are not needed for the rollforward operation.All
db2pclnrThe buffer pool page cleaners. These processes asynchronously write dirty pages from the buffer pool(s) back to disk. A dirty page is one that was changed after it was read into the buffer pool and the image on disk is no longer the same as the image in the buffer pool.

When the page cleaners are "triggered" they will all run at the same time. Once they complete their assigned work they sleep until triggered again.

Page cleaners work to ensure that there is room in the buffer pools for new pages being retrieved for applications

The number of page cleaners per database is configured by the NUM_IOCLEANERS database configuration parameter.

db2pfchrThe buffer pool prefetchers. These processes read data and index information from disk and into the database buffer pool(s) before it is read on behalf of applications. Prefetchers perform this "read-ahead" asynchronously.

The DB2 agents, acting on behalf of the applications send prefetch requests which are serviced by the prefetchers. The prefetchers perform big-block I/O to read the data more efficiently.The number of prefetchers per database is configured by the NUM_IOSERVERS database configuration parameter.


Table 4. Other processes classified by function

db2bmThe backup/restore buffer manipulator. This process is used to read from a table space during a backup operation, and to write to a table space during a restore operation. There will be one db2bm process per backup/restore buffer configured on the BACKUP or RESTORE command.All
db2fmpFenced processes to run user code on the server outside the firewall for both stored procedures and user defined functions.

The db2fmp is always a separate process, but may be multithreaded depending on the types of routines it executes.

Note: This process replaces both the db2udf and db2dari processes that were used in previous versions of DB2.
db2lbsLOAD LOB scanner. They are only used when the load tool is loading into a table with LOB columns. These processes scan the LOB object of the table and read the information back in.All
db2lbmXLOAD buffer manipulator. The last character 'X' indicates one or more. Writes loaded data to the database and can be involved in async I/O. There is always one and often more depending on a heuristic. The heuristic is based on the number of CPUs on the system and the number of containers being written to.

This "intelligent default" may be overridden by the DISK_PARALLELISM modifier to the LOAD command.

We should make it clear that this Async I/O is not the async file I/O supported by some operating systems; it just means that we have separate processes writing the I/O. This means that other processes that are formatting the data are not tied up on I/O waits.
db2lfrmXLOAD formatter process. The last character 'X' indicates one or more. This process formats the input data into internal form. It is always present in a LOAD. An intelligent default is used which may be overridden by the CPU_PARALLELISM modifier to choose the optimum number of CPUs.All
db2lfsThese process are used when the table being loaded has LONG VARCHAR columns. These are used to read and format the LONG VARCHAR columns in the table.All
db2lmrThis is the LOAD Media Reader process. It reads the load input file(s) and will disappear once the input file(s) have been read completely. This will happen even before the entire load operation has completed.All
db2lmwXThese are the LOAD media writer processes. The last character 'X' indicates one or more.

These processes make the "load copy" if this option is specified for the LOAD comamnd. The load copy is essentially a backup of the data that was loaded into the table.

These media writers are the same as the media writers used by BACKUP and RESTORE. There is one media writer invoked per copy session as described on the command line (you can create a load copy to multiple files). If there is no load copy there is no media writer. They get input from the other processes in load depending on what the data type is, but typically every bit of data that gets written by a buffer manipulator will be passed on to the media writer. As with all the other processes they are controlled by the load agent.
db2lridThis process performs the index sort and builds the index Record IDs (RIDs) during the LOAD.

This process is not present in a non-parallel database instance, i.e. INTRA_PARALLEL is disabled. The tasks performed by this process are done by the formatter EDU in a non-parallel instance.

This process performs three functions:
  • SMP synchronization
  • Allocate RIDs, the last is to build the indexes
  • Control the synchronization of the LOAD formatter processes
db2ltscThe LOAD table scanner. These processes scan the data object for the table being loaded and read the information for the LOAD tool. These are used during a LOAD append operation.All
db2linitThe LOAD initialization subagent. This subagent acquires the resources required on the database partitions and serializes the reply back to the load catalog subagent.Multi-partitioned database environment only
db2lcataThe LOAD catalog subagent. This subagent is executed only on the catalog partition and is responsible for:
  • Spawning the initialization subagents
  • Processing their replies
  • Storing the lock informationat the catalog partition.

The catalog subagent also queries the system catalog tables to determine which partitions to use for data splitting and partitioning.

There is only one catalog subagent for a normal load job. The exception are loads failing to acquire loading resources on some partitions. If setup errors are isolated on database partitions, the coordinator will remove the failed partitions from the load's internal partition list and spawn a new catalog subagent. This process is repeated until resources are successfully acquired on all partitions, or failures are encountered on all partitions.
Multi-partitioned database environment only
db2lpprtLoad pre-partition subagent. This subagent pre-partitions the input data from one input stream into multiple output streams, one for each partitioning subagent.

There will be one pre-partitioning subagent for each input stream.

Multi-partitioned database environment only
db2lpartThe load partition subagent. This subagent partitions the input data into multiple output streams, one for each database partition where the data will be written.

The number of partitioning subagents can be configured by the user. The default number depends on the total number of output database partitions.
Multi-partitioned database environment only
db2lmibmThe load mini buffer manipulator subagent processes.

This subagent writes the partitioned output file if the partition_only mode is used for the load.

There is one mini buffer manipulator subagent per output database partition.
Multi-partitioned database environment only
db2lloadThe load subagent processes. This subagent is responsible for carrying out the loading on each database partition. It spawns the formatters, ridder, buffer manipulators and media writer EDUs and oversees their work.

There is one load subagent for each output database partition.
Multi-partitioned database environment only
db2lrdflThe load read-file subagent processes. This subagent reads the message file on a given database partition and sends the data back to the client. There will be a read-file subagent for each output partition, partitioning partition and pre-partitioning partitionMulti-partitioned database environment only
db2llqclThe load query cleanup subagent processes. This subagent removes all of the load temporary files from a given partition.

There is one cleanup subagent for each output partition, partitioning partition and pre-partitioning partition.
Multi-partitioned database environment only
db2lmitkThe load mini-task subagent processes. This subagent frees all LOB locators used in a load from cursor call or a CLI load.

There is one mini-task subagent per cursor/CLI load running on the coordinator partition.

Multi-partitioned database environment only
db2lurexThe load user-exit subagent processes. This subagent runs the user's file transfer command.

There will be one user-exit subagent for each load job using the file transfer command option.
Multi-partitioned database environment only
db2lmctkThis process is used to hold, release or downgrade locks held on the catalog partition as a result of the loadMulti-partitioned database environment only
d2medThese processes handle the reading from and/or writing to the database table spaces for LOAD, backup and restore.

They write the data in formatted pages to the table space containers.
db2reorgThis process is used to perform the new online - inplace reorg in DB2 V8.1. This works similar to a disk defrag tool, placing the data rows in the specified order.All

Table 5. Some commonly used executables

db2The DB2 Command Line Processor (CLP) foreground process. It parses DB2 commands, SQL statements, etc.

This process is the the interactive component of the DB2 CLP.

This front-end/back-end configuration does have some advantages for command line performance: The front-end handles the connection to the user, and the back-end interfaces with the database.

You can use CTRL-C/CRTL-Break to stop processing (i.e. when too many records are returned) without killing the connection to the database.
db2bpThis is the persistent background process for the DB2 CLP, and it is the process which actually connects to the database.

Since the DB2 CLP allows OS as well as DB2 commands/statements, this background process is required.
db2cmdSimilar to the db2 executable, but for Windows. The db2cmd invokes a Windows command window. On Windows, parent threads cannot terminate their child processes when they are terminated. The DB2 Command Line Processor has a front-end and back-end process/thread, so we need a cookie (launched from DB2CMD.EXE) to tie these threads together on Windows so that the back end process is terminated if the user exits or kills the front end process.Windows only
db2startUser command to start up the DB2 engine.All
db2star2The real db2start program.All
db2stopUser command to stop the DB2 engine.All
db2stop2The real db2stop program.All

Table 6. Other Windows services/processes

db2dasrrm.exeThe DB2 Admin Server process. This process supports both local and remote administration requests using the DB2 Control Center.
db2dasstm.exeThe DB2 Admin Server tools DB manager process. This process stores info in and retrieves info from the tools database, if it has been set up on the DB2 server.
db2fmp.exeThe process that handles / executes all fenced stored procedures and UDFs.
db2rcmd.exeDB2 Remote Command Service which automatically handles inter-partition administrative communications.
db2jds.exeThe DB2 JDBC applet server service. This service intercepts and handles all JDBC applications connecting to the DB2 server.
db2licd.exeThe DB2 license daemon. This process verifies that a correct DB2 license is installed on the server when DB2 is started.
db2sec.exeThis process is used to check the userid and password on the DB2 server on Windows. Since DB2 relies on operating system level authentication, this process is used to verify the user id and password when a user or application connects to a database on the server. This authentication will occur when authentication is set to SERVER, or when a connection is made from a non-secure operating system.
db2syscs.exeThe main DB2 system controller or engine on Windows. The EDUs are threads within this process.

Note the 's' at the end for a Windows service.

IWH2SERV.EXEThe Warehouse Manager Center. This is installed as part of DB2 ESE, but is not part of the DB2 engine.

The following table may be a helpful index to find a given process. It lists all processes in alphabetic order with links to the tables above.

Table 7. All processes in alphabetical order

1db2Table 5
2db2agentTable 2
3db2agentgTable 2
4db2agnscTable 2
5db2agntaTable 2
6db2agntpTable 2
7db2bmTable 4
8db2bpTable 5
9db2cartTable 1
10db2chkauTable 1
11db2ckpwTable 1
12db2cmdTable 5
14db2dasrrm.exeTable 6
15db2dasstm.exeTable 6
16db2dispTable 1
17db2dlockTable 3
18db2estorTable 3
19db2fcmdTable 1
20db2fmcdTable 1
21db2fmdTable 1
22db2fmpTable 1 and Table 6
23d2fmtlgTable 1
24db2gdsTable 1
25db2glockTable 1
26db2govdTable 1
27db2ipccmTable 2
28db2jds.exeTable 8
29db2lbmXTable 4
30db2lbsTable 4
31db2lcataTable 4
32db2lfrmXTable 4
33db2lfsTable 4
34db2licd.exeTable 6
35db2linitTable 4
36db2lloadTable 4
37db2llqclTable 4
38db2lmctkTable 4
39db2lmibmTable 4
40db2lmitkTable 4
41db2lmrTable 4
42db2lmwXTable 4
43db2loggrTable 3
44db2loggwTable 3
45db2logtsTable 3
46db2lpartTable 4
47db2lpprtTable 4
48db2lrdflTable 4
49db2lridTable 4
50db2ltscTable 4
51db2lurexTable 4
52db2medTable 4
53db2panicTable 1
54db2pclnrTable 3
55db2pdbcTable 1
56db2pfchrTable 3
57db2rcmd.exeTable 6
58db2rebalTable 1
59db2reorgTable 4
60db2resynTable 1
61db2sec.exeTable 6
62db2snacmTable 2
63db2srvlstTable 1
64db2startTable 5
65db2star2Table 5
66db2stopTable 5
67db2stop2Table 5
68db2syscTable 1
69db2syscs.exeTable 6
70db2tcpcmTable 2
71db2tcpdmTable 2
72db2wdogTable 1
73dlasyncTable 1


The following section shows you examples of the output you may obtain when executing the ps -ef command in AIX.

After a db2start:

    root 49504     1   0 13:13:07      -  0:00 db2wdog 
db2inst1 22142 49180   0 13:13:10      -  0:00 db2gds 
db2inst1 43072 49180   0 13:13:17      -  0:00 db2syslog 
db2inst1 45294 74134   0 12:12:43  pts/2  0:00 /usr/bin/ksh 
db2inst1 49180 49504   0 13:13:10      -  0:00 db2sysc 
db2inst1 55920 49180   0 13:13:19      -  0:00 db2resync 
db2inst1 59012 22142   0 13:13:19      -  0:00 db2srvlst 
db2inst1 60680 49180   0 13:13:17      -  0:00 db2ipccm

The database manager configuration file has the following settings that affect the processes that you will initially see:

Max number of existing agents           (MAXAGENTS) = 200 
Agent pool size                    (NUM_POOLAGENTS) = 100(calculated) 
Initial number of agents in pool   (NUM_INITAGENTS) = 0

Because NUM_INITAGENTS is zero, there will be no 'db2agent (idle)' processes displayed at db2start time. If for example NUM_INITAGENTS had been set to 5 before the db2start, then these extra processes would have shown after issuing a db2start:

db2inst1 35542 59814   0 16:25:57      -  0:00 db2agent (idle) 
db2inst1 43096 59814   0 16:25:57      -  0:00 db2agent (idle) 
db2inst1 49628 59814   0 16:25:57      -  0:00 db2agent (idle) 
db2inst1 58170 59814   0 16:25:57      -  0:00 db2agent (idle) 
db2inst1 64012 59814   0 16:25:57      -  0:00 db2agent (idle)

After connecting to database SAMPLE (NUM_INITAGENTS still left at zero)

    root 49504     1   0 13:13:07    -  0:00 db2wdog 
db2inst1 25844 35124   0 16:04:50    -  0:00 db2pfchr 
db2inst1 35124 65638   0 16:04:17    -  0:00 db2gds 
db2inst1 35540 35124   0 16:04:50    -  0:00 db2loggr (SAMPLE) 
db2inst1 41940 65638   0 16:04:19    -  0:00 db2resync 
db2inst1 45058 35124   0 16:04:50    -  0:00 db2pfchr 
db2inst1 49300 35124   0 16:04:19    -  0:00 db2srvlst 
db2inst1 49626 35124   0 16:04:50    -  0:00 db2dlock (SAMPLE) 
db2inst1 55852 65638   0 16:04:17    -  0:00 db2ipccm 
db2inst1 58168 35124   0 16:04:50    -  0:00 db2loggw (SAMPLE) 
db2inst1 59048 35124   0 16:04:50    -  0:00 db2pfchr 
db2inst1 64010 55852   0 16:04:50    -  0:00 db2agent (SAMPLE) 
db2inst1 65638 22238   0 16:04:17    -  0:00 db2sysc 
db2inst1 70018 35124   0 16:04:50    -  0:00 db2pclnr 
db2inst1 72120 35124   0 16:04:51    -  0:00 db2event (DB2DETAILDEADLOCK) 
db2inst1 74198 65638   0 16:04:17    -  0:00 db2syslog 
db2inst1 74578     1   0 16:04:47    -  0:00 /home/db2inst1/sqllib/bin/db2bp  
  50112C14631 5

After connecting to the SAMPLE database, the 'db2agent (SAMPLE)' process appears. This process indicates there is in fact a connection to the SAMPLE database. If we issued the command:

db2 connect reset

The db2agent (SAMPLE) would now become db2agent (idle). This is because NUM_POOLAGENTS is set to a number greater than zero, which means the agent will remain allocated in the pool, though it is idle. If NUM_POOLAGENTS had been set to zero, then after the 'connect reset', there would have been no db2agent process running.

The database configuration file for the SAMPLE database has these settings:

Number of asynchronous page cleaners   (NUM_IOCLEANERS) = 1 
Number of I/O servers                   (NUM_IOSERVERS) = 3

Note that there are three db2pfchr processes which correspond to the value of NUM_IOSERVERS, and one db2pclnr process which corresponds to the value of NUM_IOCLEANERS.


There are many other processes that will appear and disappear depending on different DB2 actions and configuration settings. We've shown you some sample scenarios that illustrate how you can investigate which processes are running, what these processes indicate, and how they are affected by the database settings. Now you can use this knowledge to improve your ability to administer DB2 databases.


Special thanks to Bob Harbus of the IBM Toronto Lab Services Consulting team for his input to this document.

Downloadable resources


Sign in or register to add and subscribe to comments.

Zone=Information Management
ArticleTitle=Everything You Wanted to Know About DB2 Universal Database Processes