DB2 Universal Database Process full contact _DB2

Brief introduction

UNIX and Linux users typically check the processes running on their servers to perform problem analysis and to check the resources consumed in the server. This information is useful not only for administrators who perform issues and resource analysis, but also for those who develop high availability and failover scripts that monitor the DB2 process to determine when operations such as database restarts or server failover are required.

If you are using AIX, you can use the command Ps-ef to check the process. On Solaris and HP-UX, PS-EF will only display the DB2SYSC process (the main DB2 engine process) for all server-side processes, such as agents, loggers, page scavengers, and prefetching programs. If you are using Solaris or HP-UX, you can see these server-side processes using the command/USR/UCB/PS-AXW. Both versions of the PS command can be used on Linux.

When you execute this command on a computer running DB2 common database client or server software, you may see several DB2 processes listed. The purpose of this article is to document these processes and explain their effects and when they might run. Although the manual DB2 the 2nd chapter of the UDB V8 administration guide-performance Records Most important processes, the list is incomplete. By reading this article, you will understand each DB2 process, and when you see those processes, you will begin to understand what DB2 is doing.

Note that the implementation of DB2 on Windows differs slightly from that based on Linux and UNIX environments. In Windows, there is only one process (DB2SYSC), and each engine dispatch unit (engine dispatchable unit,edu) under that process is implemented as a thread. Although this article discusses processes, you should think of them as threads in a Windows environment. With 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'll explain what they are in this article.

Warning. Do not intervene directly in the DB2 process in the normal DB2 environment. Using the kill-9 command to kill DB2 processes in Linux or UNIX can cause abnormal behavior in DB2. For example, killing the DB2SYSC process will cause the entire DB2 instance to stop running. This article is designed to help you understand processes rather than directly manipulate them.

Why study the DB2 process.

Our personal experience has shown that this knowledge is valuable, and the customers we visit are also seeking such information from us. Don't believe it yet. Take a look at the actual scenario below and see for yourself how to solve the problem by checking the DB2 process running on the system:

Scenario 1: Rare Buffer pool page cleanup

A customer who runs an E-commerce (ecommerce) site and uses DB2 as a database server reports that the response time of the database to application requests becomes very long throughout the day. The database snapshot does not show that any exceptions occurred at that time. By checking CPU usage at a certain point in time on the server, we can determine that the I/O cleaner (DB2PCLNR) consumes more than 90% of the CPU time. Then, by studying the I/O cleanup triggers and tuning them accordingly, we eliminated this situation, enabling the E-commerce site to handle more than 50% per day throughput.

Scenario 2: The Truth

When visiting an IBM business partner for some DB2 performance tuning, we encountered a full extension of query response time. In addition to regular programs, commands that display the list of applications do not show that any other programs are running at that time. Before we got the DB2 snapshot, we looked at the DB2 process running on the DB2 server and found that the Db2rebal process was running. When a container is added to the DMS table space, the process is used to perform the rebalancing of the data. The customer "admits" that earlier that day he added a container to the table space containing the GB table. Once the rebalancing is completed, the query response time resumes as before.

Uncover the truth of notifications and diagnostics logs

Management notification logs and diagnostic logs (Db2diag.log) are important tools that administrators can use to understand the activities and capabilities of the database. These logs typically contain information about the DB2 process, as shown in the following example from the Db2diag.log item:

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:sample dia9999e a
internal return code O Ccurred. The following:
"0xffffe10e".

In this example, the message comes from a process with a process identification number of 78121. The name of the process is db2agent and is connected to a database named TEST. Understanding the functionality of a process can help you understand the meaning of each of the management notification logs and Db2diag.log.

DB2 Process Model

Although the DB2 process model is described in the DB2 Administration guide-performance Manual, this article will give a brief overview of it. First, describe the concept of an agent (the agent).

Agent Program

An agent can be considered a "worker program" that performs all database operations on behalf of an application. There are two main DB2 agent programs:

Coordinator Agent (Coordinator agent) (Db2agent)

The coordinator agent coordinates work on behalf of an application and communicates with other agents using interprocess communication (IPC) or remote communication protocols. All connection requests from the client application, whether local or remote, are assigned the appropriate coordinator agent.

Sub-agent (subagent) (DB2AGNTP)

If the Intra_parallel Database Manager configuration parameter is enabled, the coordinator agent distributes the database request to the child agent (DB2AGNTP). These agents execute the application's request. Once the coordinator agent is created, the coordinator agent processes all database requests on behalf of its application by coordinating the child Agents (Db2agent) that execute the request against the database.

When an agent or a child agent completes its task, it becomes idle. When the child agent is idle, its name changes from DB2AGNTP to Db2agnta.

For example:

DB2AGNTP processes are active child agents that are currently performing the work of the coordinator agent. These processes exist only if the parallelism is enabled in the partition.

The Db2agnta process is an idle child agent that the coordinator agent has used in the past.

The idle agent resides in an agent pool. These agents can be used for coordinator agents that operate on behalf of the client program, or for requests from child agents that act on behalf of an existing coordinator agent. The number of agent programs available depends on the database Manager configuration Parameters maxagents and num_poolagents.

Later in this article we will describe other agent types, such as the Parallel Recovery agent (DB2AGNSC).

The following two images show the DB2 process model.

Figure 1. DB2 process model with no connection set (for non-partitioned databases)

The circle in Figure 1 represents the engine dispatch unit (EDU), called a process on the Linux/unix platform, and is called a thread on Windows.

Application A (app a) and B (app B) are local applications, and the machines that run them are the same machines that reside on the DB2 server. When these applications issue a connect command connecting to the database, the DB2IPCCM listener process establishes communication between the Database manager and the application. DB2IPCCM will also work with Coordinator Agent EDU (Db2agent), which contacts the client application directly to establish communication between the client application and the coordinator for shared memory. Once this communication is established, the application on the local client is connected to the database.

Application C (app c) is a remote application that resides on a different machine than the one used for the DB2 server. The remote client establishes TCP/IP traffic through the DB2TCPCM listener process. DB2TCPCM then works with Db2agent, which becomes the coordinator for the application and passes the connection to the agent. The coordinator agent then contacts the remote client application and is connected to the database.

Figure 2. DB2 process model with no connection set (applicable to partitioned databases)

Figure 2 is similar to Figure 1, but it applies to partitioned databases. Node0000 and Node0001 represent two different machines, each of which resides on a subset of the databases. The processes and interactions between them are the same as described in Figure 1, but there are other processes that apply only to the environment. For example, the db2fcmd process is the Rapid Communications Manager (Fast Communication manager) process that manages communication between different partitions. The tables in the next section describe the other processes that apply to the partitioned database in more detail.

Process

The following tables list all the DB2 processes based on each instance, each database, and by function. Note that some of the processes in the following table are not listed in alphabetical order, but are grouped by functionality. If you want to find the process in alphabetical order, see table 7 below.

Table 1. Processes per instance-no connection, no active databases

The process name describes the scope Db2cart determines when the log file is archived and invokes the user's export to perform the actual archive work. Each instance has a Db2cart process, but the process runs only if at least one of the databases in the instance has USEREXIT enabled. All Db2chkau are used by the DB2 Audit tool to log some items to the audit log. The process is active only when auditing is enabled. All DB2CKPW are used to check the user identification and password on the DB2 server. Because DB2 relies on authentication at the operating system level, a user or application is used to authenticate a user's identity and password when connected to a database on the server. Authentication occurs when the authentication is set to SERVER, or when the connection is established from an unsecured operating system. Unix/linux Db2disp DB2 Agent dispatcher process. When a connection set is enabled, the process assigns application connections between the logical agents assigned to the application and the available coordination agents.

　　The process only exists when a connection set is enabled. All Db2fcmd FCM (Fast Communication Manager) daemon for handling communication between partitions. There is one such process for each server, each partition. Applies only to the multi-partition database environment DB2FMCD fault Monitor coordinator (Fault Monitor Coordinator) daemon process. Each physical machine has one such process. Applies only to the fault monitor daemon process initiated by the UNIX DB2FMD for each DB2 instance monitored by the fault monitor. The process is monitored by the Coordination Daemon (DB2FMCD), so if you kill the DB2FMD process, then DB2FMCD will make it rerun. Applies only to UNIX DB2FMTLG the log file is preconfigured in the log path when the database is configured to Logretain on and USEREXIT off. If the work is done, the engine process does not have to wait while the normal process is switched from one log file to another. All Db2gds DB2 the Global daemon derivative (Global Daemon spawner) process, which initiates all DB2 EDU (processes) on UNIX. There is one db2gds per instance or per database partition. Applies to UNIX Db2glock global deadlock detectors only. This process coordinates the information gathered from the Db2dlock process on each database partition to check for deadlock situations between database partitions. The Db2glock process runs on the directory partition of a multiple-partition database. It is only applicable to the DB2GOVD DB2 controller of the multi-partition database environment, it is a reactive management process. If the DB2 controller is enabled, the process takes a snapshot according to the time interval specified in the controller configuration file and checks the snapshot against all configuration rules. If a rule is violated, the specified action is taken. All Db2panic emergency agent procedures. If the agent on any database partition is not idle, the process handles some urgent requests. Applies only to multiple partitioned database environments Db2pdbc PDB (parallel databases, Parallel database) controllers. It processes parallel requests from remote nodes. Applies only to multiple partitioned database environments Db2rebal the balancer process. This process is invoked when the container is added to an existing tablespace and needs to be balanced against existing data. The process performs the rebalancing work asynchronously. All Db2resyn Resync Manager processes to support all DB2SRVLST applications that use the two-phase commit process for managing systems(such as os/390) address list. All DB2SYSC master DB2 system controllers or engines. Without the process, the database server will not be able to run. All Db2syslog system logger processes. The process is written to the operating system's error logging tool. On UNIX, you must edit the file syslog.conf to enable the process. On Windows, DB2 automatically writes the Windows event log. All Db2wdog DB2 caretaker procedures. In Unix, this process is required because a process in UNIX can only track the identity of its parent process. Each time the new process is started, Db2gds notifies the DB2 watcher. If any DB2 process receives a ctrl-c or other abnormal signal, the process sends a signal to the Watcher, and the watcher propagates the signal to all other processes in the instance. Applies only to the monitor for the UNIX dlasync DB2 Data Link (File Manager) server. The process exists only if the DB2 is configured with a data link. Applies only to Data Link table 2. Each instance and each connection

The process name describes the scope of application Db2agent DB2 Coordinator agent, which executes all database requests on behalf of an application. Each connected application will have a db2agent process unless the connection concentrator is enabled.

If partition-side parallelism is enabled, then the db2agent process invokes the DB2 child agent to perform the work, and they return the result set to the coordinator agent and then back to the application.

In a partitioned database, the coordinator agent is located on the partition to which the application is connected. Gateway Agent for all DB2AGENTG DRDA application requestors (Application requester). All DB2AGNSC parallel recovery agents. This agent is used during roll forward and restart recovery to perform operations in the log in parallel. This can shorten recovery time compared to serial recovery.

Note: This process supports parallelism in logged transactions and parallelism between parallel transactions. All Db2agnta idle child agents that were previously used by the coordinator agent and are still associated with the coordinator agent process.

This process occurs when the Intra_parallel dbm CFG parameter is set to YES. All DB2AGNTP This is a child agent that represents the coordinating agent associated with it to perform the current work. These processes provide partitioned parallelism, which is the ability to execute queries in parallel in a database instance/partition.

This process occurs when the Intra_parallel dbm CFG parameter is set to YES. All DB2IPCCM IPC Communication Manager. Each database partition has one such manager. This is the interprocess communication listener for the local client connection.

A local client connection is a connection established by an application (such as CLP) on the same computer that is running the DB2 server. All DB2TCPCM TCP Communication Manager. It acts as a communication listener for TCP/IP connection requests. When a listener receives a connection request, it relates the connection to the agent and then continues to listen for more connection requests. All DB2TCPDM communication listeners for TCP/IP discovery requests. When the Configuration Assistant (CA) searches the network for a remote DB2 server and its database, it makes a discovery request. All DB2SNACM SNA/APPC Communication Manager. It acts as the communication listener for the SNA/APPC connection request. When a listener receives a connection request, it relates the connection to the agent and then continues to listen for more connection requests. All tables 3. Each instance and each active database

Process Name Description Scope Db2dlock Local deadlock detectors, each database partition has such a detector. It scans the locked list and finds the deadlock situation. When a deadlock situation is encountered, one of the applications/transactions involved is selected as "victim" and rolled back. All db2estor are used to replicate the pages between the database buffer pool and the extended storage. These processes only appear when the database's extended storage is enabled. All Db2event Event monitor processes. Each active event monitor has a db2event process for each active database. These processes capture the defined "event" and write to the output file specified for the event monitor. All DB2LOGGR database log readers. The process reads the database log files when the following actions are performed:

Transaction processing (that is, rollback)

Reboot recovery

Roll forward operations all DB2LOGGW database loggers. The process refreshes the log files on the disk using log records for the log buffers. All Db2logts This process is used to collect information about the history of which logs are active when a table space is modified. This information is recorded in the DB2TSCHG of the database directory. His file. You can use this process to accelerate table space roll-forward recovery by enabling the skip action, which is to skip those log files that are not required by the roll forward operation. All DB2PCLNR Buffer pool page cleanup programs. These processes asynchronously write a dirty page back to disk from the buffer pool. The dirty page is a page that changes the page after it has been read into the buffer pool, and the image on the disk is no longer the same as the image in the buffer pool.

When the page cleaner is "triggered", they all run at the same time. Once they have completed their assigned work, they go to sleep until they are triggered again.

The task of the page cleaner is to ensure that the buffer pool has room to accommodate new pages that are being retrieved by the application.

The number of page scavengers per database is configured through the num_iocleaners database configuration parameters. All DB2PFCHR buffer pool prefetching procedures. These processes represent the application reading the information from disk before reading data and index information and reading the information into the database buffer pool. The prefetch program asynchronously performs this "read-read-ahead" operation.

DB2 agents that work on behalf of an application send prefetch requests that are serviced by the prefetch program. The prefetch program performs large chunks of I/O to read data more efficiently. The number of prefetch programs for each database is configured by the Num_ioservers database configuration parameter. All Tables 4. Other processes categorized by function

The process name describes the applicable scope DB2BM backup/restore buffer manipulator. This process is used to read from the tablespace during the backup operation, and to write to tablespaces during the recovery operation. Each backup/recovery buffer configured through the Backup or RESTORE command will have a DB2BM process. All DB2FMP This is a protected process for running user code on a server outside the firewall, which has both stored procedures and user-defined functions.

DB2FMP is always a stand-alone process, but it can also be multithreaded depending on the type of routines it executes.

Note: This process replaces both the DB2UDF and Db2dari processes used in previous versions of DB2. All db2lbs LOAD LOB scanners. Use them only when the loading tool is loading tables with LOB columns. These processes scan the table's LOB objects and read the information back into the table. All db2lbmx LOAD buffer manipulators. The last character "X" represents one or greater number. The process writes the loaded data to the database and may involve asynchronous I/O. "X" is always 1, but it is usually a larger number, depending on the heuristic value (heuristic). The heuristics value depends on the number of CPUs on the system and the number of containers being written.

This "smart default" may be overwritten by the disk_parallelism modifier of the LOAD command.

We should understand that this asynchronous I/O is not an asynchronous file I/O supported by some operating systems; it only means that we have some separate processes for writing I/O. This means that other processes that are formatting data are not bound by I/O waiting. All DB2LFRMX LOAD formatter processes. The last character "X" represents one or greater number. The process formats the input data into an internal format. It always appears in LOAD. The process uses the smart default value, which may be overwritten by the Cpu_parallelism modifier to select the optimal number of CPUs. All db2lfs Use these processes when the loaded table contains a LONG VARCHAR column. These processes are used to read and format LONG VARCHAR columns in the table. All DB2LMR This is the LOAD Media Reader (Media Reader) process. It reads the loaded input file, and the process disappears once all the input files have been read. The process disappears even before the entire mount operation completes. All db2lmwx These are the LOAD media logger processes. The last character "X" represents one or greater number.

If the mount Copy option is specified for the load command, the process will generate a mount copy. Mounting a copy is essentially a data backup that is loaded into a table.

These media loggers are the same as the media loggers used by BACKUP and RESTORE. As described on the command line, each copy session invokes a media logger (you can create a mounted copy of multiple files). If the replica is not mounted, there is no media recorder. They get input from other processes when they are loaded, depending on the type of data, but every bit of data written by the buffer manipulator is usually passed to the media recorder. As with all other processes, they are controlled by the loading agent. All Db2lrid The process performs index sorting during LOAD and builds the index record identity (the records Id,rid).

The process does not appear in a non-parallel database instance (that is, an instance that disables Intra_parallel). The tasks performed by this process are performed by the formatter EDU in a non-parallel instance.

The process completes the following three functions:

SMP Sync

Assign RID and the last one will build the index

Controls the synchronization of the load formatter process for all DB2LTSC LOAD table scanners. These processes scan the data objects, look for the loaded tables, and read the Load tool information. These processes are used during the LOAD append operation. All Db2linit LOAD initialization child agents. This child agent obtains the necessary resources on the database partition and serializes the answer back to the Mount directory child agent. Applies only to the Db2lcata LOAD directory child agent for a multiple-partition database environment. This child agent is only executed on the directory partition, and it is responsible for:

Derivation Initialization child agent

Process its answer

Stores lock information on a directory partition.

The Directory child agent also queries the system catalog table to determine which partitions are used for data partitioning and partitioning.

A normal mount job has only one directory child agent. The exception condition is that the mount cannot get the Mount resources on some partitions. If the settings error on the database partition is isolated, the coordinator removes the failed partition from the mounted internal partition list and derives a new directory child agent. This process repeats until the resources on all partitions are successfully obtained, or a failure occurs on all partitions. Applies only to multiple partitioned database environments Db2lpprt mount a pre-partition child agent. This subroutine partitions the input data from an input stream into multiple output streams, and each partition child agent has one such process.

Each input stream will have a pre-partitioned child agent. Applies only to multiple partitioned database environments Db2lpart mount partition child agents. This child agent partitions the input data into multiple output streams, and each database partition that writes the data has one such process.

The number of partition child agents can be configured by the user. The default number depends on the total number of output database partitions. Applies only to the multi-partition database environment DB2LMIBM mount the mini buffer manipulator subroutine process.

If the Partition_only method is used for loading, the child agent writes the partition's output file.

Each output database partition has a miniature buffer manipulator child agent. Applies only to the Db2lload Mount Child agent process for a multiple-partition database environment. This child agent is responsible for completing the mount operation on each database partition. It derives formatters, Ridder, buffer manipulators, and media logger EDU, and monitors their work.

Each output database partition has a Mount child agent. Applies only to the DB2LRDFL loading read File child agent process for a multiple-partition database environment. This child agent reads the message file on the given database partition and sends the data back to the client. Each output partition, partition partition, and pre partitioned partition have a read file child agent. Applies only to multiple partitioned database environments DB2LLQCL mount query clears the child agent process. This child agent removes all mounted temporary files from the given partition.

Each output partition, partition partition, and pre partitioned partition has a purge child agent. Applies only to multiple partitioned database environments DB2LMITK mount the Micro-task child agent process. This child agent frees all LOB locators that are used in a mount or CLI mount that is invoked from a cursor at a time.

Each cursor/CLI that runs on the coordinator partition has a micro-task child agent. Applies only to multiple partition database environment Db2lurex loading user export child agent process. This child agent runs the user's file Transfer command.

Each mount job that uses the file Transfer command option will have a user export child agent. Applies only to a multiple-partition database environment DB2LMCTK The process is used to hold, release, or demote (downgrade) locks held on a directory partition due to loading. Applies only to multiple partitioned database environments d2med These processes read and/or write to the database tablespace for LOAD, backup, and recovery.

They write data from the formatted page to the Tablespace container. All db2reorg This process is used to perform a new online-in-place reorganization operation in DB2 V8.1. The process works like the defragmentation debris tool, which places rows of data in a particular order. All tables 5. Some common executable files

The process name describes the applicable scope DB2 DB2 command line processor (CLP) foreground process. it resolves DB2 commands and SQL statements, and so on.

The process is an interactive component of the DB2 CLP.

This front-end/back-end configuration does have some benefits for command-line performance: the front-end is processed to the user's connection, and the backend is connected to the database.

You can use Ctrl-c/crtl-break to stop processing (that is, when too many records are returned) without having to kill the connection to the database. All db2bp This is a persistent background process for the DB2 CLP, and it is the process that actually connects to the database.

This background process is required because the DB2 CLP allows the OS and DB2 commands/statements. All db2cmd are similar to DB2 executables, but apply to Windows. Db2cmd calls the Windows Command window. On Windows, they cannot terminate their child processes when the parent thread is terminated. The DB2 command line processor has a front-end and back-end process/thread, so we need a cookie (via Db2cmd). EXE) is associated with these threads on Windows so that if the user exits or kills the front-end process, then the backend process is terminated. Applies only to Windows Db2start user commands that start the DB2 engine. All DB2STAR2 real Db2start programs. All db2stop Stop the DB2 engine's user command. All DB2STOP2 real db2stop programs. All tables 6. Other Windows Services/processes

The process name describes the Db2dasrrm.exe DB2 Management Server (admin servers) process. By using the DB2 control Center, the process supports local and remote management requests. Db2dasstm.exe DB2 Management Server Tools DB Manager process. If the process is already set up on the DB2 server, it stores the information in the tool database and retrieves the information from the tool database. Db2fmp.exe the process to process/execute all protected stored procedures and UDF. The Db2rcmd.exe DB2 Remote Command service, which automatically handles management traffic between partitions. Db2jds.exe DB2 JDBC Applet Server service. This service intercepts and processes all JDBC applications connected to the DB2 server. Db2licd.exe DB2 License Daemon. This process verifies that the correct DB2 license is installed on the server when the DB2 is started. Db2sec.exe Use this process on a Windows DB2 server to check the user identification and password. Because DB2 relies on authentication at the operating system level, a user or application is used to authenticate a user's identity and password when connected to a database on the server. This authentication is done when the authentication is set to SERVER, or when the connection is established from an unsecured operating system. Db2syscs.exe the primary DB2 system controller or engine on Windows. EDU is the thread in the process.

Note that the "s" at the end represents the Windows service. Iwh2serv. EXE Warehouse Manager Centre (Warehouse Manager Center). The center is installed as part of the DB2 ESE (rather than as part of the DB2 engine).

The following table may be a very useful index that can be used to find a given process. It lists all processes in alphabetical order, with links to the above tables.

Table 7. All processes in alphabetical order

# process/windows Service/executable file name to link to table with 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 Db2chkau table 1 DB2CKPW table 1 db2cmd table 5 Db2dasrrm.exe table 6 Db2dasstm.exe Table 6 db2disp Table 1 db2dlock table 3 db2estor table 3 db2fcmd table 1 DB2FMCD table 1 DB2FMD table 1 DB2FMP table 1 and table 6 D2FM TLG Table 1 db2gds table 1 db2glock table 1 db2govd table 1 db2ipccm table 2 db2jds.exe table 8 db2lbmx table 4 db2lbs table 4 DB2 Lcata Table 4 db2lfrmx table 4 db2lfs table 4 db2licd.exe table 6 db2linit table 4 db2lload table 4 Notoginseng DB2LLQCL table 4 DB2LMCTK table 4 DB2LMIBM Table 4 DB2LMITK table 4 DB2LMR table 4 db2lmwx table 4 DB2LOGGR table 3 DB2LOGGW table 3 Db2logts table 3 Db2lpart Table 4 db2lpprt Table 4 DB2LRDFL table 4 db2lrid table 4 DB2LTSC table 4 Wuyi Db2lurex table 4 db2med table 4 db2panic table 1 I Db2pcln R Table 3 DB2PDBC table 1 DB2PFCHR table 3 db2rcmd.exe table 6 Db2rebal table 1 db2reorg table 4 Db2resyn table 1 Db2sec.exe Table 6 DB2SNACM Table 2 DB2SRVlst Table 1 Db2start table 5 db2star2 table 5 db2stop table 5 DB2STOP2 table 5 DB2SYSC table 1 db2syscs.exe table 6 DB2TCPCM table 2 DB2TCPDM Table 2 db2wdog table 1 dlasync table 1 Iwh2serv. EXE Table 6

Example

The following section shows you some examples of output that might be obtained when you execute the PS-EF command in AIX.

After running 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 : Db2srvlst
db2inst1 60680 49180 0 13:13:17-0:00 db2ipccm

The Database Manager configuration file contains the following settings that affect the process that you initially saw:

Max Number of existing agents (maxagents) =
Agent Pool Size (num_poolagents) = + (Calculated)
I Nitial number of agents in pool (num_initagents) = 0

Because the num_initagents is 0, the db2agent (idle) process is not displayed when you run Db2start. For example, if you set num_initagents to 5 before running Db2start, the following additional processes are displayed after the Db2start is issued:

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) C3/>db2inst1 64012 59814 0 16:25:57-0:00 db2agent (idle)

After you connect to the database SAMPLE (the num_initagents value remains 0)

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:0 4: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 db2i PCCM
db2inst1 58168 35124 0 16:04:50-0:00 DB2LOGGW (SAMPLE)
db2inst1 59048 35124 0 16:04:50-0:00 db2pfchr< C10/>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 (DB2DETAILDEADLO CK)
db2inst1 74198 65638 0 16:04:17-0:00 db2syslog db2inst1
74578 1 0 16:04:47-0:00/home/db2inst1/sql LIB/BIN/DB2BP
50112c14631 5
  

The db2agent (sample) process appears after you connect to the sample database. The process indicates that there is actually a connection to the SAMPLE database. If we issue the following order:

DB2 Connect Reset

Db2agent (SAMPLE) will now become db2agent (idle). This is because the num_poolagents is set to a number greater than 0, which means that the agent, although idle, will still remain in the allocated state in the pool. If the num_poolagents is set to 0, the db2agent process will no longer run when connect reset is running.

The database configuration file for the SAMPLE database contains the following settings:

Number of asynchronous page cleaners (num_iocleaners) = 1 Number of
I/O servers (num_ioservers) = 3

Note that there are three DB2PFCHR processes (corresponding to the value of the num_ioservers) and a DB2PCLNR process (corresponding to the num_iocleaners value).

Conclusion

Depending on the DB2 operation and configuration settings, there will be many other processes appearing and disappearing. We've shown you some sample scenarios that demonstrate how you can see which processes are running, what these processes indicate, and how the database settings affect them. You can now use this knowledge to improve your ability to manage DB2 databases.