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

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.

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 ifPrefetching 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 Fast Communications Manager (FCM) processes (daemons) are responsible for inter-partition communications.