db2cart

DB2 coordinator/coordinating agent which performs all database requests on behalf on 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 application.

In a partitioned database, the coordinator agent will exist on the partition which the application connected to.

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.

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.

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 seperate 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.

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.

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 CPU's 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.

The LOAD initialization subagent. This subagent is executed only on the catalog partition and is responsible for:

• Spawning the initialization subagents
• Processing their replies
• 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 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.

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 EDU's and oversees their work.

There is one load subagent for each output database partition.

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.

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.

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.

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 command. 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 wirters 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 bya buffer manipoulator will be passed on to the media writer. As with all the other processes they are controlled by the load agent.

The database log reader. This process reads the database log files during:

• transaction processint (i.e. rollback)
• restart recovery
• rollforward operations

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.

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.

This process performs the index sort and builds the index Record ID's(RID's) 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:

• SMP synchronization
• Allocate RID's, the last is to build the indexes
• Control the synchronization of the LOAD formatter processes

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.

These processes handle the reading from and/or writing to the database tablespaces for LOAD, BACKUP, and RESTORE.

They write the data in formatted pages to the tablespace containers.

the buffer pool prefetchers. These processes read data and index information from disk and into the database bufferpools before it is read on behalf of applications. Prefetchers perform this "read-ahead" asynchronlusly.

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.

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.

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 bufferpools for new pages being retrieved for applications.

The number of page cleaners per database is configured by the NUM_IOCLEANERS database configuration parameter.