Section 14.1. The DB2 Process Model: The Big Picture

14.1. The DB2 Process Model: The Big Picture

Figure 14.1 shows the DB2 engine process model. This illustrates what happens behind the scenes when a client application connects to a DB2 database.

Figure 14.1. The DB2 process model

As shown in Figure 14.1, a client application connects to the DB2 database server using one of the supported communication protocols.

• Local client applications connect to the database server using the Inter-Process Communication (IPC) protocol.

• Remote client applications connect to the database server using the TCP/IP, NetBIOS, or Named Pipes communication protocol.

NOTE

NetBIOS and Named Pipes are only supported on Windows platforms.

When a client application connects to the database, the connection request is first accepted by a process known as the listener. There are different listeners for different communication protocols:

• db2ipccm for local client connections

• db2tcpcm for remote TCP/IP connections

• db2tcpdm for TCP/IP discovery tool requests

The Configuration Assistant (CA) on the DB2 client makes discovery requests when it is searching the network for remote DB2 servers and their databases. The remote connection listeners are enabled when the DB2COMM registry variable and the appropriate Database Manager Configuration parameters are set (see Chapter 6, Configuring Client and Server Connectivity).

The db2ipccm listener is enabled by default; therefore no additional steps are required.

After the listener accepts a client application connection, it will assign a coordinator agent, db2agent, to work on behalf of that application. This agent will communicate with the application and handle all its requests. If the database server instance is multi-partitioned, or if INTRA_PARALLEL is set to YES, the coordinator agent will distribute the work to a number of subagents, and its role changes to coordinating these subagents.

NOTE

Both the subagents and coordinator agents work on behalf of the application. They both can be referred to as the worker agents for the application.

If the access plan provided by the Access Plan Manager specifies prefetching, then the worker agents send the prefetch requests to a prefetch queue. (Prefetching means that one or more pages are retrieved from disk in the expectation that they will be required by an application. Prefetching helps improve performance by reducing the I/O wait time.)

The prefetch request queue is monitored by processes called prefetchers, which take the requests from the queue and service each request by retrieving the required data from disk into the buffer pools.

The amount of data to retrieve for each prefetch request is determined by the prefetch size of the specific table space where the data is stored. (You can optionally specify this value in the CREATE TABLESPACE and the ALTER TABLESPACE statements, using the PREFETCHSIZE parameter.) If the prefetch size is not specified for a table space, then DB2 uses the value for the DFT_PREFETCH_SZ configuration parameter as the default. The default value is AUTOMATIC, which allows DB2 to calculate an appropriate prefetch size for a table space based on the extent size, the number of containers, and the number of physical spindles per container. This frees you from having to determine the appropriate value for the table space prefetch size. The number of prefetchers is determined by the NUM_IOSERVERS database configuration parameter.

Once the required data is in the buffer pools, the worker agents then perform the updates requested by the application. These updates stay in the buffer pools until a later time, when the page cleaners kick in and start writing the changes from the buffer pool to disk in batches. The number of page cleaners is determined by the NUM_IOCLEANERS database configuration parameter. (See Chapter 16, Database Performance Considerations, for information about how the number of page cleaners and prefetchers impact performance.)

All transactions made by the application are logged into DB2 transaction logs by the logger process. Logging ensures data recoverability (see the discussion on data recovery in Chapter 13, Developing Database Backup and Recovery Solutions).

There are other database processes that exist in a DB2 engine, such as the load process shown in Figure 14.1.

In a DPF environment, the same set of processes exists in each database partition. The Fast Communications Manager (FCM) processes (daemons) are responsible for inter-partition communications.