DB2 process technical Model

DB2 process
Knowledge about technical models can help you understand how the Database Manager interacts with its associated components, and help you diagnose faults in the event of a problem.

All processes used by the DB2 database server
The technical model aims to simplify the communication between the database server and the client. It also ensures that database applications are independent from resources such as database control blocks and key database files.

The DB2 database server must perform various tasks, such as processing database application requests or ensuring that log records are written to the disk. Generally, each task is composed of an independentEngine allocable Unit
(EDU) execution.

Adopting a multi-threaded architecture has many advantages for the DB2 database server. Because the same process
All threads in the thread can share some operating system resources. Therefore, the memory and operating system resources required by the new thread are compared to the process.
Less. In addition, on some platforms, context switching time ratio of threads is
Short, which helps improve performance. Use the thread model on all platforms
The DB2 database server is easier to configure, because it is easier to allocate more edus as needed and can be dynamically allocated by multiple
Memory shared by Edu.

For each database being accessed, different edus will be started to process various database tasks, such as prefetch, communication, and logging. Database proxies are a special type
Edu, which is created to process application requests to the database.

Generally, you can use the DB2 database server to manage the EDU set. However, you can also use
DB2 tools to manage Edu. For example, you can use
Option db2pd
Command to list all active Edu threads.

Each client application connection has a coordination proxy for database operations.Coordinating agents
Works on behalf of the application and uses dedicated memory and processes as needed
Inter-Communication (IPC) or remote communication protocol communicates with other proxies.

The DB2 architecture provides a firewall for applications to communicate with DB2
The database server runs in different address spaces (Figure 1
).
The firewall separates databases and database managers from applications, stored procedures, and user-defined functions (udfs. This firewall helps maintain data integrity in the database, because it will block the application
Sequential programming errors overwrite the internal buffer or Database Manager Files. This firewall also improves reliability because application errors do not cause Database Manager crashes.

Figure 1. Process of the DB2 database system
Technical Model

Client Program

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

Listener communication listener in DB2
The database server is started when it is started. Each configured communication protocol has a listener, and the local client uses the process
Inter-Communication (IPC) listener (
Db2ipccm
). Listeners include:

• Db2ipccm
  For local Client Connection
• Db2tcpcm
  For TCP/IP connection
• Db2tcpdm
  For TCP/IP discovery tool requests

Agent

All connection requests from local or remote clients (applications) will be allocated with the corresponding coordination agent (db2agent
). After the coordination agent is created, it will execute all database requests on behalf of the application.

In the partitioned database environment or EnabledIntra-query concurrency
In the system
Db2agntp
And db2agets
). The name of the child agent associated with the application but currently idle
Db2agnta
.

Coordination Agent may:

• You have connected to the database through an alias. For example, db2agent (data1)
  Connect to the database alias data1.
• Connected to the instance. For example, db2agent (user1)
  Connect to instance user1.

DB2
The database server also instantiates other types of proxies (such as independent or sub-Coordination proxies) for specific operations. For example, an independent coordination agent
Db2agnti
Used to run the event monitor, while the sub-Coordination Agent
Db2agnsc
It is used to execute the database restart operation in parallel after an exception is disabled.

Idle proxies reside in the proxy pool. These proxies can be used to process the coordination agent program running on behalf of the client or the agent running on behalf of the existing coordination agent.
The request of the sub-agent of the row. When there is a large number of application workloads, configuring an appropriate idle proxy pool helps improve performance. In this case, you can immediately use the idle proxy as needed,
Instead of allocating a new proxy for each application connection, the latter case involves creating threads and allocating and initializing memory and other resources. DB2
The database server automatically manages the size of the idle proxy pool.

Db2fmp

Protected Process
Executes protected stored procedures and user-defined functions outside the firewall.
Db2fmp
Process
Always an independent process
But it may be a multi-threaded process.
Depends on the type of the routine it executes.

Db2vend

This is a process that represents Edu's execution of vendor code
For example, run the user exit program for log archiving (unix only ).

The following lists the important edus used by each database:

• Db2dlock
  Used for Deadlock Detection. In the partitioned database environment, use another thread (db2glock
  ) To coordinate db2dlock
  Edu
  Information collected from each partition; db2glock
  Only run on the directory partition.
• Db2hadrp
  , High availability disaster recovery (hadr) master server thread
• Db2hadrs
  , Hadr Backup Server thread
• Db2lfr
  , Used to process the log file reader of each log file
• Db2loggr
  Used to process log files for processing and recovery
• Db2loggw
  Used to write logs to log files.
• Db2logmgr
  For log manager. Manage recoverable database log files.
• Db2logts
  Used to track which tablespaces have log records in which log files. This information is recorded in the database directory db2tschg. His
  File.
• Db2lused
  Used to update object usage
• Db2pfchr
  Used for Buffer Pool prefetch.
• Db2pclnr
  Used to clear the buffer pool page.
• Db2redom
  For re-master processes
  . During the restoration period, it processes the redo log records and assigns them to the redo Worker Program for processing.
• Db2redow
  Used to redo the work program. During recovery, it follows the re-master Process
  .
• Db2shred
  Used to process various log records on the log page
• Db2stmm
  Used to adjust the memory management function
• Db2taskd
  Used to distribute background database tasks. These tasks are named db2taskp
  .
• Db2wlmd
  Used to automatically collect workload management statistics
• The event Monitor thread is identified as follows:
  • Db2evm% 1
    % 2
    (% 3
    )
    Where,% 1
    It can be:
    • G
      -Global File event monitor
    • GP
      -Global MPs event monitor
    • L
      -Local file event monitor
    • Lp
      -Local MPs queue event monitor
    • T
      -Table event monitor

    % 2
    It can be:

    • I
      -Coordination procedure
    • P
      -Not a Coordination Program

    While% 3
    Yesevent monitor name

• The Identification Method of the backup and recovery threads is as follows:
  • Db2bm.% 1
    .% 2
    (Backup and recovery buffer handlers) and
    Db2med.% 1
    .% 2
    (Backup and recovery media Controller), where:
    • % 1
      Is the edu id of the proxy program used to control backup or recovery sessions
    • % 2
      It is the sequential value used to differentiate threads that belong to a specific backup or recovery SESSION (there may be many)

    Example: db2bm. 13579.2
    Identifies a db2agent with an Edu ID of 13579
    The second db2bm under thread control
    Thread.

Database Server threads and processes

System Controller (in
Db2sysc on UNIX
, In
In Windows
Db2syscs.exe
) Must exist so that the database server can work. The following threads and processes
Various tasks will be executed:

• Db2acd
  It is used to monitor the running status, automatically maintain the utility, and manage the task scheduler's Independent Computing daemon. This process
  Previously called
  Db2hmon
  .
• Db2aiothr
  Used to manage asynchronous I/O requests for database partitions (unix only)
• Db2alarm
  Used to notify Edu when the timer of an Edu request expires (unix only)
• Db2cart
  , Used in userexit
  Archive log files when the database configuration parameters are enabled
• Db2disp
  , Client connection concentrator dispatcher
• Db2fcms
  , Fast communication manager sender daemon
• Db2fcmr
  , Fast communication manager receiver daemon
• Db2fmd
  , Fault Monitor daemon
• Db2fmtlg
  , Used in logretain
  The database configuration parameters are enabled and
  Userexit
  Format log files when database configuration parameters are disabled
• Db2licc
  To manage installed DB2 licenses
• Db2panic
  , Emergency proxy, used to process emergency requests when a specific database partition reaches the proxy limit (only used to partition the database environment)
• Db2pdbc
  , Parallel system controller, used to process parallel requests from remote database partitions (used only in partitioned database environments)
• Db2resync
  To scan the global synchronization list and then synchronize the proxy process.
  
• Db2sysc
  , The Master System Controller Edu; it handles critical DB2 server events
• Db2thcln
  , Restart the resource upon Edu termination (unix only)
• Db2wdog
  , In UNIX and
  Handle Abnormal Termination of the guard program on the Linux operating system