Learn more about the DB2 Universal Database Process (1)

Introduction

UNIX and Linux users often check the processes running on the server for problem analysis and check the resources consumed on the server. This information is not only useful to system administrators who solve problems and analyze resources, but also for developing high availability and monitoring DB2 processes to determine when to execute a behavior (such as database restart) or execute the necessary server error recovery scripts (failover.

If you use AIX, you must use the ps-ef command to check the process. On Solaris and HP-UX, ps-ef displays db2sysc processes (Major DB2 engine processes) only for all server-side processes (such as agents, loggers, page cleaners, and prefetchers ). If you are using Solaris or HP-UX, you can see these processes using the/usr/ucb/ps-axw command. These ps commands can all work on Linux.

When you run this command on a computer running the DB2 Universal Database client or server software, you can see that multiple DB2 processes are listed. The purpose of this article is to describe these processes and explain what they are and when they will run. By reading this article, you can understand every process of DB2 and what operations DB2 is performing when you see these processes.

Note: in DB2, how the process is executed is slightly different for Windows, Linux, and UNIX environments. In Windows, there is only one process (db2sysc), in which each engine can allocate a unit (EDU) for execution as a thread. Although processes are discussed in this article, they should be considered as threads in Windows. In the Windows Task Manager, you can view the db2syscprocess (db2syscs.exe) of each worker ). Other Windows Services/processes can also be displayed. This article will explain what they are.

Warning do not directly interfere with the DB2 process in a normal DB2 environment. Using the kill-9 command in Linux or UNIX to delete a DB2 process may cause abnormal DB2 behavior. If the process is deleted, the entire DB2 instance is stopped. The purpose of this article is to understand these processes rather than directly maintaining them.

Why check the DB2 process?

Our personal experience has shown the value of this knowledge, and the customers we visit also ask us about this type of information. Let's take a look at the following real situation and see how you can check the DB2 process running on the system to solve the problem:

Case 1: rare buffer pool page cleanup

A customer who runs an e-commerce website and uses DB2 as a database server reports that it takes a long time for the database to respond to applications in multiple periods of the day. During these periods, database snapshots do not show abnormal behaviors. By checking the CPU usage of processes in one of the time periods, we can find that the I/O cleaning device (db2pclnr) consumes more than 90% of the CPU time. Next, by checking the I/O clearing process triggers and adjusting them appropriately, we have eliminated this situation and the processing capability of the e-commerce site has increased by more than 50%.

Case 2: Actual Situation

Although I visited an IBM business partner and made some DB2 performance adjustments, we still encountered a common response delay. The application LIST command does not display any abnormal processes at this time. Before obtaining the DB2 snapshot, we checked the DB2 process running on the DB2 server and found that the db2rebal process is running. When adding a container to the DMS tablespace, this process is used to perform another data balancing. The customer admitted that on that day it added a container to a tablespace containing a 40 Gb table. After the rebalancing is completed, the query response speed returns to normal.
View notification and diagnosis logs

Managing notification logs and diagnostic logs (db2diag. log) is an important tool for system administrators to understand database activities and functions. Normally, they contain information about the DB2 process. The following example shows a db2diag. log entry:

2000-03-06-11.53.18.001160 Instance: myInst Node: 000 PID: 78121 (db2agent (TEST) TID: 352 Appid: * LOCAL. payroll.000306140834lock _ manager sqlplrq Probe: 111 Database: TEST DIA9999E An internal return code occurred. report the following: "0xFFFFE10E ".

In this example, the process ID of the message source is 78121. The name of this process is db2agent, And it connects to the database named TEST. Understanding what each process is doing helps you understand the system management notification log and db2diag. log content.
　　
DB2 process model

Proxy
A proxy can be considered as a "working program" that performs database operations required by all applications. There are two types of DB2 proxies:

◆ Db2agent)

The programme agent represents the application and communicates with other proxies using interprocess communication (IPC) or remote communication protocol. All client application connection requests, whether local or remote, will be assigned a corresponding Coordination Program proxy.

◆ Sub-proxy (db2agntp)

When intra_parallel Database Manager is allowed to configure parameters, the coordinating program proxy allocates database requests to the sub-proxy (db2agntp ). These proxies execute requests for the application. Once a Coordination Program proxy is established, it processes all database requests by coordinating the sub-proxies that execute database requests.

When a proxy or sub-proxy completes its work, it becomes idle. When a sub-proxy becomes idle, its name changes from db2agntp to db2agnta.

For example:

Db2agntp is the active sub-proxy and is executing Work for the coordinating program proxy. These processes exist only when the intra-partition parallelism is allowed.

Db2agnta is an idle sub-proxy which was used by the coordinating program proxy in the past. The idle proxy is located in the proxy pool. These proxies are available for requests from the Coordination Program proxy representing the client program. The number of available proxies depends on the configuration parameters maxagents and num_poolagents of the Database Manager.
Later sections of this article will explain other types of proxies (such as the parallel reply proxy and db2agnsc ). The following two charts show the DB2 process model.

Figure 1: DB2 process model without a connection set (for a database without partitions)

Each circle in Figure 1 represents the engine allocable unit (EDU), which is a process on the Linux/UNIX platform and a thread in Windows.

Both application A (App A) and application B (App B) are local applications running on the DB2 server. When these applications request a CONNECT to the database, the db2ipccm listening process establishes communication between the database manager and the application. Db2ipccm also uses a Coordination Program to act as the EDU (db2agent). It directly connects to the client application to establish shared memory communication between the client application and the proxy. Once the communication is established, the application of the local client is connected to the database.

Application C (App C) is a remote application located on another computer outside the DB2 server. The remote client establishes TCP/IP communication through the db2tcpcm listening process. Then the db2tcpcm works with the db2agent, which becomes the Coordination Program proxy of the application and passes the connection to the proxy. After that, the agent contacts the remote client application and connects to the database.

Figure 2: DB2 process model without a connection set (for partitioned databases)

Figure 2 is similar to Figure 1 but can be used in partitioned databases. Node0000 and Node0001 represent two different computers with the database partitions on them respectively. The interaction between the process and them is the same as that in Figure 1, but some processes can only be used in such an environment. For example, db2fcmd is the Fast Communication Manager Process, which is used to manage Communication between different partitions. The following table details other processes used to partition the database.

Processes

The following table lists all DB2 processes for each instance and database based on their functions. Note that some processes in the following table are not grouped in alphabetical order, but based on functional groups.

Table 1: processes of each instance-databases without connection or activity

Table 2: each instance and each connected Process

Table 3: processes of each instance and each active database