Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you an example analysis of the db2 process model. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Technical model of DB2 process

The process technology model used by all DB2 database servers is designed to simplify communication between the database server and the client. It also ensures that database applications are independent of resources such as database control blocks and critical database files.

The DB2 database server must perform various tasks, such as processing database application requests or ensuring that log records are written to disk. Typically, each task is performed by a separate engine dispatchable unit (EDU).

Adopting multithreaded architecture has many advantages for DB2 database servers. Because all threads within the same process can share some operating system resources, new threads require less memory and operating system resources than processes. In addition, on some platforms, threads have shorter context switching times than processes, which helps improve performance. Using the threading model on all platforms makes the DB2 database server easier to configure because it makes it easier to allocate more EDU as needed and to dynamically allocate memory that must be shared by multiple EDU.

For each database accessed, a different EDU is started to handle various database tasks, such as prefetching, communication, and logging. Database agents are a special class of EDU that are created to handle application requests to the database.

Typically, you can rely on the DB2 database server to manage EDU collections. However, you can also manage EDU through some DB2 tools. For example, you can use the db2pd command with the-edus option to list all active EDU threads.

Each client application connection has a coordination agent that performs operations on the database. The orchestration agent works on behalf of the application and communicates with other agents using dedicated memory, interprocess communication (IPC), or remote communication protocols as needed.

Client program

The client program can be a remote program or a local program running on the same machine as the database server. The client program first contacts the database through a communication listener.

Listener

The communication listener starts when the DB2 database server starts. Each configured communication protocol has a listener, and the local client program uses an interprocess communication (IPC) listener (db2ipccm). Listeners include:

Db2ipccm for local client connections

Db2tcpcm for TCP/IP connection

Db2tcpdm for TCP/IP Discovery tool request

Agent program

All connection requests from local or remote client programs (applications) will be assigned a corresponding coordinator agent (db2agent). After the coordinator agent is created, it executes all database requests on behalf of the application.

In a partitioned database environment or in a system with intra-query parallelism enabled, the coordinator agent distributes database requests to the subagents (db2agntp and db2agnts). The subagent associated with the application but currently idle is named db2agnta.

The coordinator agent may:

Connected to the database through an alias; for example, db2agent (DATA1) will connect to the database alias DATA1.

Connected to the instance; for example, db2agent (user1) will connect to the instance user1.

The DB2 database server also instantiates other types of agents, such as stand-alone coordinator agents or sub-coordination agents, in order to perform specific operations. For example, the stand-alone coordinator agent db2agnti is used to run the event monitor, while the child coordination agent db2agnsc is used to perform database restart operations in parallel after an abnormal shutdown.

The gateway agent (db2agentg) is an agent associated with a remote database. It provides an indirect connection to allow clients to access the host database.

The idle agent resides in the agent pool. These agents can be used to process requests from a coordinating agent running on behalf of a client program or from a subagent running on behalf of an existing coordinating agent. When there are a large number of application workloads, having an idle agent pool of the right size can help improve performance. In this case, the idle agent can be used immediately as needed without the need to allocate a new agent for each application connection, which involves creating threads and allocating and initializing memory and other resources. The DB2 database server automatically manages the size of the idle agent pool.

You can associate a pooling agent to a remote or local database. Agents that share on a remote database are called shared gateway agents (db2agntgp). Agents that work on the local database are called pooled database agents (db2agentdp).

Db2fmp

Protected mode processes are responsible for executing protected stored procedures and user-defined functions outside the firewall. The db2fmp process is always a stand-alone process, but it may be multithreaded, depending on the type of routine it executes.

Db2vend

The db2vend process executes vendor code on behalf of EDU; for example, execute a user exit program for log archiving (UNIX only).

Database EDU

The following list includes some important EDU used by each database:

Db2pfchr for buffer pool prefetching program

Db2pclnr for buffer pool page cleaners

Db2dlock for deadlock detection. In a partitioned database environment, another thread (db2glock) is used to coordinate the information that db2dlock EDU collects from each partition; db2glock runs only on directory partitions. The db2glock EDU is used to coordinate db2dlockEDU launches on each db2glock EDU on each member, but only one EDU is active.

Db2fw, an event monitor quick writer; used for massive, parallel writing of event monitor data to tables, files, or pipes.

Db2fwx, the event monitor quickly writes the program thread, where "x" identifies the thread number. During database activation, the DB2 engine sets the number of db2fwx threads to a value that performs best for event monitors and avoids potential performance problems when running different types of workloads. The number of db2fwx threads is equal to the number of logical CPU on the system (for multicore CPU, each core is treated as a logical CPU). For instances in a partitioned database environment, the number of derived db2fwx threads is equal to the number of logical CPU per member of each database divided by the number of local partitions on the host.

Db2hadrp, High availability disaster recovery (HADR) master server thread

Db2hadrs,HADR standby server thread

Db2lfr, a log file reader for processing individual log files

Db2loggr for processing log files to handle transactions and recovery

Db2loggw, used to write log records to the log file

Db2logmgr for the log manager. Manage log files for recoverable databases.

Db2logts, which tracks which tablespaces are logged in which log files. This information is recorded in the DB2TSCHG.HIS file in the database directory.

Db2lragen, used to generate log sequence numbers for the new central server threading model (if a valid XML resource policy with database scope is defined). In large NUMA systems, this may improve performance and result in a high update rate.

Db2lused for updating object purpose

Db2pcsd for automatic purging of the package cache

Db2redom, used to redo the main process. During recovery, it processes redo logging and assigns it to the redo worker for processing.

Db2redow, used to redo the work program. During recovery, it handles redo logging in accordance with the request to redo the main process.

Db2shred, which is used to handle individual logging in the log page

Db2stmm for self-tuning memory management function

Db2taskd to distribute background database tasks. These tasks are performed by a thread named db2taskp.

Db2wlmd for automatic collection of workload management statistics

Event monitor threads are identified as follows:

G-Global File event Monitor

Gp-Global Pipe event Monitor

L-Local File event Monitor

Lp-Local Pipe event Monitor

T-table event monitor

I-coordinator

P-not a coordinator

Db2evm%1%2 (3)

Where% 1 can be:

% 2 can be:

And 3 is the event monitor name

Backup and recovery threads are identified as follows:

1 is the EDU identity of the agent used to control backup or restore sessions

2 is the sequence value used to distinguish threads (there may be many) belonging to a specific backup or recovery session

Db2bm.%1.%2 (backup and recovery buffer manipulator) and db2med.%1.%2 (backup and recovery Media Controller), where: db2bm.13579.2 identifies the second db2bm thread controlled by the db2agent thread with EDU identification 13579.

The following database EDU is used in the

Db2LLMn1, used to process db2LLMn2 and db2LLMng, to ensure that pending locks on this member are released in time (if other members are waiting for them)

Db2LLMrl for processing db2LLMrc for database recovery operations and database server threads and processes

The system controller (db2sysc on UNIX and db2syscs.exe on Windows operating system) must exist for the database server to work. The following threads and processes perform various tasks:

Db2acd, an autonomous computing daemon for supervising health monitors, automatic maintenance utilities, and administrative task schedulers. This process was formerly known as db2hmon.

Db2aiothr, which is used to manage asynchronous Icano requests for database partitions (UNIX only)

Db2alarm, used to notify EDU when the timer they requested expires (UNIX only)

Db2disp, client connection concentrator dispatcher

Db2fcms, Fast Communications Manager sender daemon

Db2fcmr, Fast Communications Manager receiver daemon

Db2fmd, fault monitor daemon

Db2licc, managing installed DB2 licenses

Db2panic, the emergency startup agent, is used to process emergency requests after the agent limit has been reached.

Db2pdbc, the parallel system controller, to handle parallel requests from remote database partitions (for partitioned database environments only)

Db2resync, the resynchronization agent process that scans the global resynchronization list

Db2rocm and db2rocme, in db2sysc, the main system controller EDU;, which handles critical DB2 server events

Db2sysc (idle), DB2 idle processes, which allow a quick and lightweight restart of the guest db2thcln on the host, restart resources when the EDU terminates (UNIX only)

Db2wdog, handling abnormally terminated caretaker programs on UNIX and Linux operating systems

Db2wlmt,WLM dispatcher schedules threads

Db2wlmtm,WLM dispatcher timer thread

The above is the example analysis of the db2 process model shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.