The Db2 process model

Knowledge of the Db2 process model helps you to understand how the database manager and its associated components interact. This knowledge can help you to troubleshoot problems that might arise.

The process model that is used by all Db2 database servers facilitates communication between database servers and clients. It also ensures that database applications are isolated from resources, such as database control blocks and critical database files.

The Db2 database server must perform many different tasks, such as processing database application requests or ensuring that log records are written out to disk. Each task is typically performed by a separate engine dispatchable unit (EDU).

There are many advantages to using a multithreaded architecture for the Db2 database server. A new thread requires less memory and fewer operating system resources than a process, because some operating system resources can be shared among all threads within the same process. Moreover, on some platforms, the context switch time for threads is less than that for processes, which can improve performance. Using a threaded model on all platforms makes the Db2 database server easier to configure, because it is simpler to allocate more EDUs when needed, and it is possible to dynamically allocate memory that must be shared by multiple EDUs.

For each database accessed, separate EDUs are started to deal with various database tasks such as prefetching, communication, and logging. Database agents are a special class of EDU that are created to handle application requests for a database.

In general, you can rely on the Db2 database server to manage the set of EDUs. However, there are Db2 tools that look at the EDUs. For example, you can use the db2pd command with the -edus option to list all EDU threads that are active.

Each client application connection has a single coordinator agent that operates on a database. A coordinator agent works on behalf of an application, and communicates to other agents by using private memory, interprocess communication (IPC), or remote communication protocols, as needed.

While in a Db2 pureScale® instance, these processes are used to monitor the health of Db2 members and/or cluster caching facilities (CFs) running on the host, as well as to distribute the cluster state to all Db2 members and CFs in the instance.

The Db2 architecture provides a firewall so that applications run in a different address space than the Db2 database server (Figure 1). The firewall protects the database and the database manager from applications, stored procedures, and user-defined functions (UDFs). The firewall maintains the integrity of the data in the databases, because it prevents application programming errors from overwriting internal buffers or database manager files. The firewall also improves reliability, because application errors cannot crash the database manager.
Figure 1. Process model for Db2 database systems
Graphic representation of the process model for Db2database systems

Client programs

Client programs can be remote or local, running on the same machine as the database server. Client programs make first contact with a database through a communication listener.


Communication listeners start when the Db2 database server starts. There is a listener for each configured communications protocol, and an interprocess communications (IPC) listener (db2ipccm) for local client programs. Listeners include:
  • db2ipccm, for local client connections
  • db2tcpcm, for TCP/IP connections
  • db2tcpdm, for TCP/IP discovery tool requests


All connection requests from local or remote client programs (applications) are allocated a corresponding coordinator agent (db2agent). When the coordinator agent is created, it performs all database requests on behalf of the application.

In partitioned database environments, or systems on which intraquery parallelism is enabled, the coordinator agent distributes database requests to subagents (db2agntp and db2agnts). Subagents that are associated with an application but that are currently idle are named db2agnta.

A coordinator agent might be:
  • Connected to the database with an alias; for example, db2agent (DATA1) is connected to the database alias DATA1.
  • Attached to an instance; for example, db2agent (user1) is attached to the instance user1.

The Db2 database server instantiates other types of agents, such as independent coordinator agents or subcoordinator agents, to execute specific operations. For example, the independent coordinator agent db2agnti is used to run event monitors, and the subcoordinator agent db2agnsc is used to parallelize database restart operations after an abnormal shutdown.

A gateway agent (db2agentg) is an agent associated to a remote database. It provides indirect connectivity that allows clients to access the host database.

Idle agents reside in an agent pool. These agents are available for requests from coordinator agents that operate on behalf of client programs, or from subagents that operate on behalf of existing coordinator agents. Having an appropriately sized idle agent pool can improve performance when there are significant application workloads. In this case, idle agents can be used as soon as they are required, and there is no need to allocate a new agent for each application connection, which involves creating a thread and allocating and initializing memory and other resources. The Db2 database server automatically manages the size of the idle agent pool.

A pooled agent can be associated to a remote database or a local database. An agent pooled on a remote database is referred to as a pooled gateway agent (db2agntgp). An agent pooled on a local database is referred to as a pooled database agent (db2agntdp).


The fenced mode process is responsible for executing fenced stored procedures and user-defined functions outside of the firewall. The db2fmp process is always a separate process, but might be multithreaded, depending on the types of routines that it executes.


The db2vend process is a process to execute vendor code on behalf of an EDU; for example, to execute a user exit program for log archiving (UNIX only).

Database EDUs

The following list includes some of the important EDUs that are used by each database:
  • db2castructevent, handles CF departure and arrival processing in a pureScale cluster
  • db2CFConnPoolMgr, re-balances the CF connections among the member-CF links in a pureScale cluster
  • db2cfmt, dynamic CF memory tuning in a pureScale cluster
  • db2clstrRscMon, monitors the changes in states of network adapters in a pureScale cluster
  • db2dlock, for deadlock detection. In a partitioned database environment, an additional thread (db2glock) is used to coordinate the information that is collected by the db2dlock EDU on each partition; db2glock runs only on the catalog partition. In a Db2 pureScale environment, a db2glock EDU is used to coordinate the information that is collected by the db2dlock EDU on each member. A db2glock EDU is started on each member, but only one is active.
  • db2fw, the event monitor fast writer; which is used for high volume, parallel writing of event monitor data to tables, files, or pipes
    • db2fwx, an event monitor fast writer thread where "x" identifies the thread number. During database activation the Db2engine sets the number of db2fwx threads to a value that is optimal for the performance of event monitors and avoids potential performance problems when different types of workloads are run.  The number of db2fwx threads equals the number of logical CPUs on the system (for multi-core CPUs, each core counts as one logical CPU). For DPF instances, the number of db2fwx threads spawned equals to the number of logical CPUs per member, per database divided by the number of local partitions on the host.
  • db2hadrp, the high availability disaster recovery (HADR) primary server thread
  • db2hadrs, the HADR standby server thread
  • db2lfr, for log file readers that process individual log files
  • db2loggp, for periodic log work such as determining the recovery window
  • db2loggr, for manipulating log files to handle transaction processing and recovery
  • db2loggrq, for assisted remote catchup logic used by HADR in pureScale environment
  • db2loggw, for writing log records to the log files
  • db2logmgr, for the log manager. Manages log files for a recoverable database.
  • db2logts, for tracking which table spaces have log records in which log files. This information is recorded in the DB2TSCHG.HIS file in the database directory.
  • db2lused, for updating object usage
  • db2periodic, runs internal database task which need to be executed periodically
  • db2pclnr, for buffer pool page cleaners
  • db2pcsd, for autonomic cleanup of the package cache
  • db2pfchr, for buffer pool prefetchers
  • db2pkgrb, for the autonomic rebind of invalid packages. During database catalog node startup, db2pkgrb makes a single attempt to rebind each invalid package. If auto revalidation is not disabled (ie. if the auto_reval database configuration parameter is not set to DISABLED), then db2pkgrb will also attempt to rebind each inoperative package. Afterwards, it shuts down until the next startup. Just before it terminates, a summary message is written at INF level to the diag.log when it has finished processing the list. If it is the first rebind attempt after an upgrade, detailed messages for any failed rebind are written at INF level to the diag.log. For all other startups, only the summary message is generated.
  • db2redom, for the redo master. During recovery, it processes redo log records and assigns log records to redo workers for processing.
  • db2redow, for the redo workers. During recovery, it processes redo log records at the request of the redo master.
  • db2shred, for processing individual log records within log pages
  • db2stmm, for the self-tuning memory management feature
  • db2taskd, for the distribution of background database tasks. These tasks are executed by threads called db2taskp.
  • db2wlmd, for automatic collection of workload management statistics
  • db2dbctrld, for periodic database related tasks.
  • Event monitor threads are identified as follows:
    • db2evm%1%2 (%3)
      where %1 can be:
      • g - global file event monitor
      • gp - global piped event monitor
      • l - local file event monitor
      • lp - local piped event monitor
      • t - table event monitor
      and %2 can be:
      • i - coordinator
      • p - not coordinator
      and %3 is the event monitor name
  • Backup and restore threads are identified as follows:
    • db2bm.%1.%2 (backup and restore buffer manipulator) and db2med.%1.%2 (backup and restore media controller), where:
      • %1 is the EDU ID of the agent that controls the backup or restore session
      • %2 is a sequential value that is used to distinguish among (possibly many) threads that belong to a particular backup or restore session
      For example: db2bm.13579.2 identifies the second db2bm thread that is controlled by the db2agent thread with EDU ID 13579.
  • db2XInot, handles Xi invalidation in a pureScale cluster
  • The following database EDUs are used for locking in a Db2 pureScale environment:
    • db2LLMn, handles lock notifications from the CF process GLM/GCL structures in a pureScale cluster
    • db2LLMn1, to process information sent by the global lock manager; there are two of these EDUs on each member, one for the primary CF, and another for the secondary CF
    • db2LLMn2, to process information sent by the global lock manager for a special type of lock that is used during database activation and deactivation processing; there are two of these EDUs on each member, one for the primary CF, and another for the secondary CF
    • db2LLMng, to ensure that the locks held by this member are released in a timely manner when other members are waiting for these locks
    • db2LLMrl, to process the release of locks to the global lock manager
    • db2LLMrc, for processing that occurs during database recovery operations and during CF recovery
    • db2LLMrf, handles lock notification resync logic with the CF process in case of connection drop and re-establishment in a pureScale clusters

Database server threads and processes

The system controller (db2sysc on UNIX and db2syscs.exe on Windows operating systems) must exist if the database server is to function. The following threads and processes carry out various tasks:
  • db2acd, an autonomic computing daemon that hosts the health monitor, automatic maintenance utilities, and the administrative task scheduler. This process was formerly known as db2hmon.
  • db2aiothr, manages asynchronous I/O requests for a database partition (UNIX only)
  • db2alarm, notifies EDUs when their requested timer expires (UNIX only)
  • db2disp, the client connection concentrator dispatcher
  • db2fcms, the fast communications manager sender daemon
  • db2fcmr, the fast communications manager receiver daemon
  • db2fmd, the fault monitor daemon
  • db2iperiodic, the task scheduler thread. The tasks are executed by threads called db2iperiodicWatch<task_number> and db2iperiodicExec<task_number>.
  • db2licc, manages installed Db2 licenses
  • db2panic, the panic agent, which handles urgent requests after agent limits are reached
  • db2pdbc, the parallel system controller, which handles parallel requests from remote database partitions (used in both partitioned database environments and Db2 pureScale environments)
  • db2resync, the resync agent that scans the global resync list
  • db2rocm and db2rocme, while in a Db2 pureScale instance, these processes monitor the operational state of Db2 members and cluster caching facilities (CFs) running on each host, as well as to distribute cluster state information to all Db2 members and CFs in the instance.
  • db2sysc, the main system controller EDU; it handles critical Db2 server events
  • db2sysc (idle), the Db2 idle processes, which enable the restart light of a guest member on a host quickly and without competing with the resident member for resources.
  • db2syscque, message queue listener providing request queuing and distributing services to system controller in a Db2 pureScale environment.
  • db2thcln, recycles resources when an EDU terminates (UNIX only)
  • db2wdog, the watchdog on UNIX and Linux® operating systems, which handles abnormal terminations.
  • db2wlmt, the WLM dispatcher scheduling thread
  • db2wlmtm, the WLM dispatcher timer thread