14.2. The DB2 Engine Dispatchable Units Each circle shown in Figure 14.1 represents a DB2 process. The DB2 engine is where these processes live; hence these processes are called DB2 Engine Dispatchable Units (EDUs). Therefore, a coordinator agent, a page cleaner, and a subagent are all EDUs. The EDUs are implemented as processes on Linux/UNIX platforms and as threads on Windows platforms. Unless explicitly indicated, we use the term process in this chapter to refer to both processes on Linux/UNIX and threads on Windows. Figure 14.2 shows the hierarchy for some main DB2 EDUs. Figure 14.2. The main DB2 EDUs 
Figure 14.2 shows a firewall between the client applications and the DB2 engine because the client applications run in a different address space from the DB2 engine. This way, if applications behave in an inappropriate manner, they will not overwrite DB2's internal buffers or files within the DB2 engine. The db2fmp process is the fenced-mode process; it is responsible for executing fenced-stored procedures and user-defined functions outside the firewall. If stored procedures and functions are defined as unfenced, then they will run within the same address space as the DB2 engine. By doing so, the performance of stored procedures and functions can be improved. However, there is an added potential risk to the DB2 engine: These stored procedures and functions can potentially overwrite DB2 internal buffers, causing DB2 to crash. This is why stored procedures and user functions should never run unfenced unless tested thoroughly. In Figure 14.2, the EDUs are grouped in different levels. Let's look at what role each of them plays. 14.2.1. The DB2 Instance-Level EDUs The core engine process is the DB2 system controller process, db2sysc. This is the first process created when the instance starts. The db2sysc process then spawns other processes to perform various tasks, such as the listeners, which listen for client connections. Table 14.1 lists and describes the DB2 instance-level EDUs. Table 14.1. The DB2 Instance-Level EDUsProcess Name | Description | Platform |
|---|
db2cart | Determines when a log file can be archived and invokes the userexit process to do the actual archiving. There is one db2cart process per instance, but it only runs if there is at least one database in the instance that 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 | Checks user IDs and passwords on the DB2 server. Since DB2 relies on operating system-level authentication, this process verifies 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 nonsecure operating system. | UNIX / Linux | db2disp | The DB2 agent dispatcher 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 daemon for handling inter-partition communications. One per server, per partition. | Multi-partitioned database environment only | db2fmcd | The fault monitor coordinator daemon. One per physical machine. | UNIX only | db2fmd | The fault monitor daemon 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 | Preallocates 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. Starts all DB2 EDUs (processes) on UNIX. There is one db2gds per instance or database partition. | UNIX only | db2glock | Global deadlock detector. 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 governing process that 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. This process only exists when the DB2 governor is enabled. | All | db2panic | The panic agent. Handles urgent requests after agent limits have been reached on any of the database's partitions. | Multi-partitioned database environment only | db2pdbc | The Parallel Database (PDB) Controller. Handles parallel requests from remote nodes. | Multi-partitioned database environment only | db2rebal | The rebalancer process. 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. Supports applications that are using two-phase commit. | All | db2srvlst | Manages 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. 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 Linux and UNIX can only track their parent process ID. Each time a new process is started, db2gds notifies the DB2 watchdog. If any DB2 process receives a CTRL+C or other abnormal signal, the process sends the signal to the watchdog, and it propagates the signal to all of the other processes in the instance. | Linux and 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 | db2ipccm | IPC communication manager. One per database partition. This is the inter-process communication listener for local client connections. A local client connection is a connection made from an application or 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 when it is searching the network for remote DB2 servers and their databases. | All |
NOTE In a Database Partitioning Feature (DPF) environment, the same set of EDUs is created for each database partition.
Figure 14.3 shows the list of DB2 processes after an instance is started by db2start. The instance name is db2inst1, and it has two database partitions. Figure 14.3. DB2 EDUs after an instance is started root 29464 1 0 19:49:37 - 0:01 db2wdog 0 root 418132 1 0 19:49:38 - 0:01 db2wdog 1 db2inst1 121078 263592 0 19:49:46 - 0:00 db2pdbc 0 db2inst1 135778 263592 0 19:49:46 - 0:00 db2ipccm 0 db2inst1 263592 29464 0 19:49:39 - 0:00 db2sysc 0 db2inst1 269678 394674 0 19:49:45 - 0:00 db2pdbc 1 db2inst1 297878 263592 0 19:49:45 - 0:00 db2fcmdm 0 db2inst1 308610 394674 0 19:49:45 - 0:00 db2resync 1 db2inst1 315772 541832 0 19:49:47 - 0:00 db2srvlst 0 db2inst1 321520 394674 0 19:49:45 - 0:00 db2ipccm 1 db2inst1 324388 394674 0 19:49:44 - 0:00 db2gds 1 db2inst1 341672 394674 0 19:49:44 - 0:00 db2fcmdm 1 db2inst1 369054 394674 0 19:49:45 - 0:01 db2hmon 1 db2inst1 394674 418132 0 19:49:40 - 0:00 db2sysc 1 db2inst1 396446 394674 0 19:49:45 - 0:00 db2panic (idle) 1 db2inst1 405400 263592 0 19:49:47 - 0:00 db2panic (idle) 0 db2inst1 456718 263592 0 19:49:47 - 0:01 db2hmon 0 db2inst1 519040 263592 0 19:49:47 - 0:00 db2resync 0 db2inst1 541832 263592 0 19:49:41 - 0:00 db2gds 0 db2inst1 573828 324388 0 19:49:45 - 0:00 db2srvlst 1
Figure 14.3 shows that each partition has the same set of DB2 EDUs. The last column indicates the partition with which the EDU is associated. Note the db2wdog processes are owned by root, not the instance. On AIX, Linux, and HP-UX, use the ps ef | grep instancename command to display the DB2 processes owned by the instance. Alternatively, you can use the db2_ps command, which displays the DB2 processes under each database partition. On Solaris, the ps ef command only shows db2sysc for all processes (e.g., listeners, loggers, page cleaners, and prefetchers). To display the DB2 processes with their actual names, use the db2ptree command. 14.2.2. The DB2 Database-Level EDUs When a database starts, it starts several processes to handle database-level tasks such as prefetching, logging, and page cleaning. These processes are spawned by the db2gds process on Linux/UNIX platforms and by db2sysc on Windows platforms. Table 14.2 shows the DB2 EDUs at the database level. Table 14.2. The DB2 Database-Level EDUsProcess Name | Description | Applicability |
|---|
db2dlock | Local deadlock detector. One per database partition. 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 | Copies pages between the database buffer pool(s) and extended storage. These processes appear only when extended storage is enabled for a database. | All | db2event | The event monitoring process. There is 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. | | db2loggr | The database log reader. Reads the database log files during transaction processing (i.e., roll back and roll forward operations) and restart recovery. | All | db2loggw | The database log writer. Flushes log records from the log buffer to the log files on disk. | All | db2logts | Collects 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 speeds up table space roll forward recovery by enabling the skipping of log files that are not needed for the roll forward operation. | All | db2pclnr | The buffer pool page cleaners. Asynchronously writes 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.) Works to ensure that there is room in the buffer pools for new pages being retrieved for applications. When the page cleaners are "triggered," they all run at the same time. Once they complete their assigned work they sleep until triggered again. The number of page cleaners per database is configured by the NUM_IOCLEANERS database configuration parameter. | All | db2pfchr | The buffer pool prefetchers. Reads 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 |
Figure 14.4 shows the list of database-level EDUs after the SAMPLE database is started by a connection to the database. You can see that a set of database-level processes are created for each partition. For example, each partition has one db2loggr process, one db2dlock process, and three db2pfchr processes. Figure 14.4. The database-level DB2 EDUs after the SAMPLE database is started db2inst1 57846 324388 0 19:53:42 - 0:00 db2loggr (SAMPLE) 1 db2inst1 71504 541832 0 19:53:43 - 0:00 db2agent (idle) 0 db2inst1 128880 324388 0 19:53:43 - 0:00 db2event (DB2DETAILDEADLOCK) 1 db2inst1 132764 541832 0 19:53:43 - 0:00 db2pfchr 0 db2inst1 135778 263592 0 19:49:46 - 0:00 db2ipccm 0 db2inst1 169298 541832 0 19:53:43 - 0:00 db2pfchr 0 db2inst1 183970 541832 0 19:53:42 - 0:00 db2lfr (SAMPLE) 0 db2inst1 205302 324388 0 19:53:42 - 0:00 db2lfr (SAMPLE) 1 db2inst1 213500 324388 0 19:53:42 - 0:00 db2pfchr 1 db2inst1 218468 541832 0 19:53:43 - 0:00 db2pclnr 0 db2inst1 246144 541832 0 19:53:43 - 0:00 db2dlock (SAMPLE) 0 db2inst1 275236 324388 0 19:53:42 - 0:00 db2dlock (SAMPLE) 1 db2inst1 355768 324388 0 19:53:42 - 0:00 db2loggw (SAMPLE) 1 db2inst1 381136 541832 0 19:53:42 - 0:00 db2loggw (SAMPLE) 0 db2inst1 419484 541832 0 19:53:43 - 0:00 db2pfchr 0 db2inst1 439484 324388 0 19:53:42 - 0:00 db2glock (SAMPLE) 1 db2inst1 458448 324388 0 19:53:42 - 0:00 db2agntp (SAMPLE) 1 db2inst1 468242 324388 0 19:53:42 - 0:00 db2pclnr 1 db2inst1 483634 541832 0 19:53:42 - 0:00 db2loggr (SAMPLE) 0 db2inst1 492846 324388 0 19:53:42 - 0:00 db2pfchr 1 db2inst1 532004 324388 0 19:53:42 - 0:00 db2pfchr 1 db2inst1 546646 135778 0 19:53:42 - 0:00 db2agent (SAMPLE) 0
14.2.3. The Application-Level EDUs Application-level EDUs are agents. After the listener process accepts a client connection, it takes a free agent, db2agent, from the idle agent pool. If no free agent is available, a new db2agent will be created. The db2agent becomes the coordinator agent for the application, and it will perform all database operations on behalf of the application. There are four types of DB2 agents. Coordinator agents Active subagents Associated subagents Unassociated agents
A coordinator agent (db2agent) coordinates the work on behalf of an application and communicates to other agents using the inter-process communication (IPC) protocol (for local connections) or remote communication protocol (for remote connections). Each connection request from client applications is allocated a coordinator agent. Figure 14.4 shows that the db2agent process db2inst1 546646 135778 0 19:53:42 - 0:00 db2agent (SAMPLE) 0
is assigned to a connection to the SAMPLE database. The SAMPLE in parenthesis indicates the database name that the db2agent is associated with. Note that this db2agent process is created by the db2ipccm process. (Its parent PID 135778 matches the db2ipccm process in Figure 14.3.) Because this is a local connection, db2ipccm was the responsible listener for accepting the connection, and it spawned this agent to handle this connection request. There is one coordinator agent (i.e., the db2agent process) per connection, unless the connection concentrator is enabled. (We discuss the connection concentrator in section 14.5, The Connection Concentrator.) In a partitioned database environment, the coordinator agent exists on the partition that the application is connected to. In this example, it exists on partition 0 (this is indicated by the 0 beside SAMPLE), because this is the partition from where the connection request was issued. In a DPF environment, or when the INTRA_PARALLEL Database Manager Configuration parameter is enabled, the coordinator agent distributes the database requests to an active subagent, db2agntp. These subagents perform the work and return the result set to the coordinator agent to return to the application. In Figure 14.4, one subagent, db2agntp, is shown: db2inst1 458448 324388 0 19:53:42 - 0:00 db2agntp (SAMPLE) 1
This is because db2inst1 is a multi-partition instance with two database partitions. This subagent works for the coordinator agent 546646 on database partition 1. When a subagent completes its work it becomes an associated (idle) subagent. It changes its name from db2agntp to db2agnta, and it is returned to the application's agent pool. However, it is still associated with the application. When needed, it is called by the coordinator agent or the active subagents to service the same application again. Or it can be stolen by another application, if that application cannot find an idle agent or no more agents can be created (MAXAGENTS is reached). This improves performance by minimizing the creation and destruction of EDUs. The idle db2agnta agents remain associated with the application as long as the total number of idle agents in the instance does not exceed the value of the NUM_POOLAGENTS Database Manager Configuration parameter. If the number of NUM_POOLAGENTS has already been reached, then the db2agnta process disassociates itself from the application and terminates. If subagents must be constantly created and reassociated to applications, performance suffers. (See Chapter 16, Database Performance Considerations, for a discussion on tuning of the NUM_POOLAGENTS parameter.) Unassociated agents are idle agents (db2agent) not associated with any existing applications. They are ready for use by any incoming client connections, and can be called by any coordinator agents or active subagents to perform work. Figure 14.4 shows an idle db2agent: db2inst1 71504 541832 0 19:53:43 - 0:00 db2agent (idle) 0
Again, the number of idle agents is determined by the NUM_POOLAGENTS Database Manager Configuration parameter. The DB2 agent pool is shared by all databases in an instance, not just one database. Table 14.3 lists the DB2 EDUs at the application level. Table 14.3. The DB2 Application-Level EDUsProcess Name | Description | Applicability |
|---|
db2agent | DB2 coordinator/coordinating agent that performs all database requests on behalf of an application. There is one db2agent process per connected application, unless the connection concentrator is enabled. If intra-partition parallelism is enabled, the db2agent process calls the DB2 subagents to perform the work, and they return the result set to the coordinator agent to return to the application. In a partitioned database, the coordinator agent exists on the partition which the application connected to. | All | db2agentg | The gateway agent for DRDA application requesters. | All | db2agnsc | The parallel recovery agent. During roll forward and restart recovery, performs 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 used in the past by a coordinating agent and still associated to that coordinating agent process. Appears when the INTRA_PARALLEL dbm cfg parameter is set to YES or in a partitioned database environment. | 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, that is, the ability to execute a query in parallel within a database instance/partition. Appears when the INTRA_PARALLEL dbm cfg parameter is set to YES or in a partitioned database environment. | All |
14.2.4. Per-Request EDUs Table 14.4 lists the per-request DB2 EDUs. Table 14.4. The DB2 Per-Request EDUsProcess Name | Description | Applicability |
|---|
db2bm | The Backup/Restore buffer manipulator. Reads from a table space during a backup operation and writes to a table space during a restore operation. One db2bm process per backup/restore buffer is configured on the backup or restore command. | All | db2fmp | Fenced processes that 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. 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') is a numeric identifier for the process. Writes loaded data to the database and can be involved in asynchronous I/O. There is always one, and often more, depending on a heuristic, which 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. Note: This asynchronous I/O is not the asynchronous file I/O supported by some operating systems; it just means there are separate processes writing the I/Othat other processes are formatting the data and are not tied up on I/O waits. | All | db2lfrmX | LOAD formatter process. The last character (X) is a numeric identifier. This process formats the input data into internal form. It is always present in a LOAD. An intelligent default is used, but can be overridden by the CPU_PARALLELISM modifier to choose the optimum number of CPUs. | All | db2lfs | 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 | The LOAD media reader process. Reads the load input file(s) and disappears once the input file(s) have been read completelyeven before the entire load operation has completed. | All | db2lmwX | The LOAD media writer processes. The last character (X) is a numeric identifier. These processes make the "load copy" if this option is specified for the load command. The load copy is essentially a backup of the data that was loaded into the table. These are the same as the media writers used by the backup and restore commands. 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 | Performs the index sort and builds the index RIDs during the LOAD. This process is not present in a nonparallel database instance, that is, if INTRA_PARALLEL is disabled. The tasks performed by this process are done by the formatter EDU in a nonparallel instance. This process performs four functions: synchronizes SMP, allocates Record IDs (RIDs), builds the indexes, and controls the synchronization of the LOAD formatter processes. | All | db2ltsc | The Load table scanner. Scans the data object for the table being loaded and reads the information for the Load tool. These are used during a Load append operation. | All | db2linit | The Load initialization 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. Is executed only on the catalog partition and is responsible for spawning the initialization subagents and processing their replies, and storing the lock information at the catalog partition. 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 is when loads fail to acquire loading resources on some partitions. If setup errors are isolated on database partitions, the coordinator will remove the failed partitions from 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 prepartition subagent. This subagent pre-partitions the input data from one input stream into multiple output streams, one for each partitioning subagent. There is one pre-partitioning subagent per 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. You can configure the number of partitioning subagents with the PARTITIONING_DBPARTNUMS load option. 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. 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. Carries out the loading on each database partition, and 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. 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. 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. 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. Runs the user's file transfer command. There is one user-exit subagent for each load job using the FILE_TRANSFER_CMD option of the load command. | Multi-partitioned database environment only | db2lmctk | Holds, releases, or downgrades locks held on the catalog partition as a result of the load. | Multi-partitioned database environment only | db2med | Handles the reading from and/or writing to the database table spaces for the load, backup, and restore commands, and writes the data in formatted pages to the table space containers. | All | db2reorg | Performs the new online-inplace reorg in DB2 Version 8.1. This works similar to a disk defrag tool; it places the data rows in the specified order. | All |
Figure 14.5 shows the EDUs created during a database backup operation. Figure 14.5. The DB2 EDUs responsible for backing up a database db2inst1 71504 541832 0 19:53:43 - 0:00 db2bm.546646.0 0 db2inst1 328336 541832 0 19:59:37 - 0:00 db2med.546646.0 0 db2inst1 541832 263592 0 19:49:41 - 0:00 db2gds 0
|
