Learning Visually with Examples [Electronic resources] نسخه متنی

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

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

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

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

db2lbm

X

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

db2lfrm

X

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