Troubleshooting Guide

Description of the DB2 Process Model

The process model used by all DB2 servers facilitates the communication that occurs between database servers and client and local applications. It also ensures that database applications are isolated from resources such as database control blocks and critical database files.

UNIX-based environments use an architecture based on processes. For example, the DB2 communications listeners are created as processes. Intel operating systems such as OS/2 and Windows NT use an architecture based on threads to maximize performance. For example, the DB2 communications listeners are created as threads within the DB2 server's system controller process. The process model for DB2 describes the behavior of processes and threads.

For each database being accessed, various processes/threads are started to deal with the various database tasks (for example, prefetching, communication, and logging).

Each process/thread of a client application has a single coordinator agent that operates on a database. A coordinator agent works on behalf of an application, and communicates to other agents using inter-process communications (IPC) or remote communication protocols.

DB2 architecture provides a firewall so that applications run in a different address space from DB2. The firewall protects the database and the database manager from applications, stored procedures, and user-defined functions (UDFs). A firewall maintains the integrity of the data in the databases, because an application programming error cannot overwrite an internal buffer or file of the database manager. It also improves reliability, because an application programming error cannot crash the database manager.

Figure 1. Process Model for DB2 Systems

The following list provides additional details on the processes/threads shown in Figure 1:

Client Programs

Client programs run remotely or on the same machine as the database server. They make their first contact with the database through a listener. A coordinator agent (db2agent) is then assigned to them.

Listeners

Client programs make initial contact with communication listeners, which are started when DB2 is started. There is a listener for each configured communication protocol, and an inter-process communications (IPC) listener (db2ipccm) for local client programs. Listeners include:

• db2ipccm, for local client connections
• db2tcpcm, for TCP/IP connections
• db2snacm, for APPC connections
• db2tcpdm, for TCP/IP discovery tool requests

To find out if there was a problem activating a listener, consult the db2diag.log at the server. For more information, see Using the db2diag.log File to Diagnose Server Communication Problems.

Agents

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

In some environments in which 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 (db2agntp) that perform requests on the database.

A coordinator agent may 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".

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.

db2udfp

Fenced user-defined functions (UDFs) run outside of the firewall.

db2dari

Fenced stored procedures run outside of the firewall.

Database Threads/Processes

The following list includes some of the important threads/processes used by each database:

• db2pfchr, for input and output (I/O) prefetching
• db2pclnr, for buffer pool page cleaners
• db2loggr, for manipulating log files to handle transaction processing and recovery
• db2dlock, for deadlock detection.

Database Server Threads/Processes

The system controller (db2sysc) must exist in order for the database server to function. Also, the following threads/processes may be started to carry out various tasks:

• db2resyn, the resync agent that scans the global resync list
• db2gds, the global daemon spawner on UNIX-based systems that starts new processes
• db2wdog, the watchdog on UNIX-based systems that handles abnormal terminations
• db2fcmdm, the fast communications manager daemon for handling internodal communication (used only in DB2 Enterprise - Extended Edition)
• db2pdbc, the parallel system controller, which handles parallel requests from remote nodes (used only in DB2 Enterprise - Extended Edition)
• db2panic, the panic agent, which handles urgent requests after agent limits have been reached at a particular node (used only in DB2 Enterprise - Extended Edition)

Differences between Intel and UNIX

The Intel systems supported by DB2 (OS/2 and Windows) differ from UNIX-based environments in that the database engine is multi-threaded, not multi-processed. In the Intel systems, each of the dispatchable units on the agent side of the firewall is a thread under the process db2sysc, allowing the database engine to let the operating system perform task-switching at the thread level and not the process level. For each database being accessed, there are other threads started to deal with database tasks (for example, prefetching).

Another difference is in the handling of abends. There is no need for a "watchdog" process in Intel systems, because these systems ensure that the allocated resources are cleaned up after an abnormal termination. Thus, there is no equivalent of the db2wdog process on the Intel systems. In addition, the db2gds process/thread is not needed on the Intel systems, which have their own mechanisms for starting threads.