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
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.
Listeners
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
Agents
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 (db2agentdp).
db2fmp
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.
db2vend
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:
- db2pfchr, for buffer pool prefetchers
- db2pclnr, for buffer pool page cleaners
- db2loggr, for manipulating log files to handle
transaction processing and recovery
- db2loggw, for writing log records to the log
files
- 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.
- 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.
- db2stmm, for the self-tuning memory management
feature
- db2taskd, for the distribution of background
database tasks. These tasks are executed by threads called db2taskp.
- 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 DB2 engine 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
- db2loggr, for manipulating log files to handle
transaction processing and recovery
- 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
- db2pcsd, for autonomic cleanup
of the package cache
- db2pfchr, for buffer pool prefetchers
- db2pclnr, for buffer pool page cleaners
- 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
- 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.
- The following database EDUs are used for
locking in a DB2 pureScale environment:
- 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
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
- 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.
- 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
DB2 10.5 for Linux, UNIX, and Windows
