![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
© 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.
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-11.53.18.001160 Instance:myInst Node:000 PID:78121(db2agent (TEST)) TID:352 Appid:*LOCAL.payroll.000306140834 lock_manager sqlplrq Probe:111 Database:TEST DIA9999E An internal return code occurred. Report the following: "0xFFFFE10E". |
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.
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)
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 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 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
| Process name | Description | Applicability |
|---|---|---|
| db2cart | Determines 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 |
| db2chkau | Used by the DB2 audit facility to log entries to the Audit log. It is only active if auditing has been enabled. | All |
| db2ckpw | Used 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 |
| db2disp | The 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. | All |
| db2fcmd | FCM (Fast Communication Manager) daemon for handling inter-partition communications. One per server, per partition. | Multi-partitioned database environment only |
| db2fmcd | The Fault Monitor Coordinator daemon process. One per physical machine. | UNIX only |
| db2fmd | The 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 |
| db2fmtlg | Pre-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 |
| db2gds | The DB2 Global Daemon Spawner process that starts all DB2 EDUs (processes) on UNIX. There is one db2gds per instance or database partition. | UNIX only |
| db2glock | Global 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 |
| db2govd | The 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 |
| db2panic | The panic agent. It handles urgent requests after agent limits have been reached on any of the database's partitions. | Multi-partitioned database environment only |
| db2pdbc | The PDB (Parallel Database) Controller. It handles parallel requests from remote nodes. | Multi-partitioned database environment only |
| db2rebal | The 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 |
| db2resyn | The resync manager process used to support applications that are using two-phase commit | All |
| db2srvlst | Process used to manage lists of addresses for systems such as OS/390. | All |
| db2sysc | The main DB2 system controller or engine. Without this process, the database server cannot function. | All |
| db2syslog | The 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 |
| db2wdog | The 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 |
| dlasync | A 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
| Process name | Description | Applicability |
|---|---|---|
| db2agent | DB2 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. | All |
| db2agentg | The gateway agent for DRDA Application Requesters. | All |
| db2agnsc | The 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. | All |
| db2agnta | An 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. | All |
| db2agntp | A 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. | All |
| db2ipccm | IPC 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. | All |
| db2tcpcm | TCP 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 |
| db2tcpdm | Communication 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 |
| db2snacm | SNA / 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
| Process name | Description | Applicability |
|---|---|---|
| db2dlock | Local 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 |
| db2estor | Used 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 |
| db2event | The 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 |
| db2loggr | The database log reader. This process reads the database log files during:
| All |
| db2loggw | The database log writer. This process flushes log records from the log buffer to the log files on disk. | All |
| db2logts | Process 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 |
| db2pclnr | The 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. | All |
| db2pfchr | The 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. | All |
Table 4. Other processes classified by function
| Process name | Description | Applicability |
|---|---|---|
| db2bm | The 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 |
| db2fmp | Fenced 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. | All |
| db2lbs | LOAD 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 |
| db2lbmX | LOAD 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. | All |
| db2lfrmX | LOAD 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 |
| db2lfs | These 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 |
| db2lmr | This 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 |
| db2lmwX | These 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. | All |
| db2lrid | This 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:
| All |
| db2ltsc | The 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 |
| db2linit | The 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 |
| db2lcata | The LOAD catalog subagent. This subagent is executed only on the
catalog partition and is responsible for:
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 |
| db2lpprt | Load 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 |
| db2lpart | The 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 |
| db2lmibm | The 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 |
| db2lload | The 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 |
| db2lrdfl | The 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 partition | Multi-partitioned database environment only |
| db2llqcl | The 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 |
| db2lmitk | The 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 |
| db2lurex | The 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 |
| db2lmctk | This process is used to hold, release or downgrade locks held on the catalog partition as a result of the load | Multi-partitioned database environment only |
| d2med | These 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. | All |
| db2reorg | This 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
| Process name | Description | Applicability |
|---|---|---|
| db2 | The 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. | All |
| db2bp | This 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. | All |
| db2cmd | Similar 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 |
| db2start | User command to start up the DB2 engine. | All |
| db2star2 | The real db2start program. | All |
| db2stop | User command to stop the DB2 engine. | All |
| db2stop2 | The real db2stop program. | All |
Table 6. Other Windows services/processes
| Process name | Description |
|---|---|
| db2dasrrm.exe | The DB2 Admin Server process. This process supports both local and remote administration requests using the DB2 Control Center. |
| db2dasstm.exe | The 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.exe | The process that handles / executes all fenced stored procedures and UDFs. |
| db2rcmd.exe | DB2 Remote Command Service which automatically handles inter-partition administrative communications. |
| db2jds.exe | The DB2 JDBC applet server service. This service intercepts and handles all JDBC applications connecting to the DB2 server. |
| db2licd.exe | The DB2 license daemon. This process verifies that a correct DB2 license is installed on the server when DB2 is started. |
| db2sec.exe | This 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.exe | The 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.EXE | The 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
| # | Process/Windows service/Executable name | Link to table providing more details |
|---|---|---|
| 1 | db2 | Table 5 |
| 2 | db2agent | Table 2 |
| 3 | db2agentg | Table 2 |
| 4 | db2agnsc | Table 2 |
| 5 | db2agnta | Table 2 |
| 6 | db2agntp | Table 2 |
| 7 | db2bm | Table 4 |
| 8 | db2bp | Table 5 |
| 9 | db2cart | Table 1 |
| 10 | db2chkau | Table 1 |
| 11 | db2ckpw | Table 1 |
| 12 | db2cmd | Table 5 |
| 14 | db2dasrrm.exe | Table 6 |
| 15 | db2dasstm.exe | Table 6 |
| 16 | db2disp | Table 1 |
| 17 | db2dlock | Table 3 |
| 18 | db2estor | Table 3 |
| 19 | db2fcmd | Table 1 |
| 20 | db2fmcd | Table 1 |
| 21 | db2fmd | Table 1 |
| 22 | db2fmp | Table 1 and Table 6 |
| 23 | d2fmtlg | Table 1 |
| 24 | db2gds | Table 1 |
| 25 | db2glock | Table 1 |
| 26 | db2govd | Table 1 |
| 27 | db2ipccm | Table 2 |
| 28 | db2jds.exe | Table 8 |
| 29 | db2lbmX | Table 4 |
| 30 | db2lbs | Table 4 |
| 31 | db2lcata | Table 4 |
| 32 | db2lfrmX | Table 4 |
| 33 | db2lfs | Table 4 |
| 34 | db2licd.exe | Table 6 |
| 35 | db2linit | Table 4 |
| 36 | db2lload | Table 4 |
| 37 | db2llqcl | Table 4 |
| 38 | db2lmctk | Table 4 |
| 39 | db2lmibm | Table 4 |
| 40 | db2lmitk | Table 4 |
| 41 | db2lmr | Table 4 |
| 42 | db2lmwX | Table 4 |
| 43 | db2loggr | Table 3 |
| 44 | db2loggw | Table 3 |
| 45 | db2logts | Table 3 |
| 46 | db2lpart | Table 4 |
| 47 | db2lpprt | Table 4 |
| 48 | db2lrdfl | Table 4 |
| 49 | db2lrid | Table 4 |
| 50 | db2ltsc | Table 4 |
| 51 | db2lurex | Table 4 |
| 52 | db2med | Table 4 |
| 53 | db2panic | Table 1 |
| 54 | db2pclnr | Table 3 |
| 55 | db2pdbc | Table 1 |
| 56 | db2pfchr | Table 3 |
| 57 | db2rcmd.exe | Table 6 |
| 58 | db2rebal | Table 1 |
| 59 | db2reorg | Table 4 |
| 60 | db2resyn | Table 1 |
| 61 | db2sec.exe | Table 6 |
| 62 | db2snacm | Table 2 |
| 63 | db2srvlst | Table 1 |
| 64 | db2start | Table 5 |
| 65 | db2star2 | Table 5 |
| 66 | db2stop | Table 5 |
| 67 | db2stop2 | Table 5 |
| 68 | db2sysc | Table 1 |
| 69 | db2syscs.exe | Table 6 |
| 70 | db2tcpcm | Table 2 |
| 71 | db2tcpdm | Table 2 |
| 72 | db2wdog | Table 1 |
| 73 | dlasync | Table 1 |
| 74 | IWH2SERV.EXE | Table 6 |
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.
Dwaine Snow is the product manager for DB2 UDB partitioned databases as well as Query Patroller and IBM Informix IDS. Dwaine has worked for the past 12 years at IBM, and has worked with DB2 UDB for the past 8 years. You can reach Dwaine at dsnow@ca.ibm.com .
Raul F. Chong is a database consultant from the IBM Toronto Laboratory and works primarily with IBM Business Partners. Raul has worked for five years in IBM, three of them in DB2 Technical Support, and two of them as a consultant specializing in database application development and migrations from other RDBMS to DB2. You can reach Raul at rfchong@ca.ibm.com .
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
