DB2 Instance and Fast Communication Manager - Page 3

Backup and Restore Default Size

Two additional DBM parameters need to be taken into computation for the DBM global control block. These are the internal instance backup and restore buffers. They behave fully dynamically, and are allocated and deallocated only during backup and restore operations. Each call for the backup or restore utility will open a buffer and at the end of the operation close it. Such a buffering speeds the whole process and shortens the backup/recovery time. The default buffer size is predefined with the instance parameters, or it is specified on the command line, together with the database call for the backup/restore utility.

Default settings for the instance backup and restore buffer size:

# db2 get dbm cfg | grep BUFSZ
Backup buffer default size (4KB) 
           (BACKBUFSZ) = 1024
Restore buffer default size (4KB)
           (RESTBUFSZ) = 1024

The default backup buffer size is 1024 in 4KB pages, or 4MB. Backup buffer working range resulting from min 32KB to max 2GB.

The default restore buffer size is 1024 in 4KB pages, or 4MB. Restore buffer working range resulting from min 64KB to max 2GB.

FCM Shared Memory and FCM Buffer Pool

A separate memory area is allocated for the fast communication manager. The main FCM memory segments are FCM shared memory and FCM Buffer pool.

Fast Communication Manager (FCM)

The DB2 Fast Communication Manager or FCM for short is a specific IBM EDU (engine dispatchable unit) or UNIX process, that is responsible for handling database inter-parallel node communication in multimode database configuration. Inter node data and message traffic circulates over FCM shared memory structures between database partitions.

Every database partition has an associated db2fcmdm FCM deamon process, which is started during the DB2 instance start.

Let's look at the DB2 process tree (db2ptree) for a specific database configuration, with one physical and three logical nodes (partitions):

$ db2ptree
6836  -ksh
  6849  db2ptree
14174  db2wdog 0
  14180  db2sysc 0
    14196  db2gds 0
      14215  db2resyn 0
      14216  db2srvlst 0
    14197  db2fcmdm 0  -> FCM EDU or FCM deamon for partition 0
    14202  db2pdbc 0
    14203  db2ipccm 0
      14221  db2agent (idle) 0
    14204  db2tcpcm 0
      14235  db2agent (idle) 0
    14217  db2panic (idle) 0
14189  db2wdog 1
  14190  db2sysc 1
    14198  db2gds 1
      14207  db2resyn 1
      14208  db2srvlst 1
      26550  db2agent (idle) 1
    14199  db2fcmdm 1   -> FCM EDU or FCM deamon for partition 1
    14205  db2pdbc 1
    14206  db2ipccm 1
    14209  db2panic (idle) 1
14194  db2wdog 2
  14195  db2sysc 2
    14200  db2gds 2
      14212  db2resyn 2
      14213  db2srvlst 2
      26557  db2agent (idle) 2
    14201  db2fcmdm 2 -> FCM EDU or FCM deamon for partition 2
    14210  db2pdbc 2
    14211  db2ipccm 2
    14214  db2panic (idle) 2

FCM Configuration Files

During instance start, the FCM deamon process will read communication parameters from the operating system service file /etc/service as well as configuration parameters from the database configuration file, db2nodes.cfg. The dedicated port group used exclusively for FCM communication is configured in the service file:

% more /etc/services | grep DB2	
DB2_db2inst1               50000/tcp -> start FCM address
DB2_db2inst1_END           50002/tcp -> end FCM address 

Following the given example, separate TCP/IP ports (50000, 50001, and 50002) are used as FCM communication ports. Every database partition has an associated unique communication port. Each database partition in a DB2 mulitpartitioned database has the same entries in the service and database configuration files on all physical machines. Correctly defined communication ports are critical for successful, fast communication manager functioning. If they are not defined correctly, new partitions cannot be added to an existing multipartition database configuration, nor can a non-partitioned database be transformed to partitioned one.

The database configuration parameter file db2nodes.cfg contains the following partitions information:

>> cat db2nodes.cfg
0 ARTIST01 0  - > first logical DB2 partition
1 ARTIST01 1  - > second logical DB2 partition
2 ARTIST01 2  - > third logical DB2 partition

The described file consists of three entries, one per logical partition.

Once established, communication between partitions became a main lifeline for multipartition database activity.

FCM Parameters

Table with all DBM (instance) parameters related to the fast communication manager:

List of FCM parameters with associated default values for partitioned DB2 7.2 database:

# db2 get dbm cfg | grep FCM
 No. of int. communication buffers(4KB)(FCM_NUM_BUFFERS) = 1024
 Number of FCM request blocks              (FCM_NUM_RQB) = 512
 Number of FCM connection entries      (FCM_NUM_CONNECT) = (FCM_NUM_RQB * 0.75) 
 Number of FCM message anchors         (FCM_NUM_ANCHORS) = (FCM_NUM_RQB * 0.75) 

List of FCM parameters with associated default values for partitioned DB2 8.1 database:

# db2 get dbm cfg | grep FCM
No. of int. communication buffers(4KB)(FCM_NUM_BUFFERS) = 4096

FCM parameters descriptions:

fcm_num_buffers - the amount of FCM communication buffers, with default value 4096 in 4KB pages for partitioned DB2 database.

fcm_num_rqb - the amount of FCM request blocks used for communication between the FCM daemon and agent or between agents. Default value for partitioned database is 2048 in 4KB pages.

fcm_num_connect - the number of FCM connection entries used for inter-agents data communication. The default value for partitioned databases totals 1536 in 4KB pages.

fcm_num_anchors = the message registers used for inter-agents message communication. The default value for partitioned databases totals to 1536 in 4KB pages.

Review of default values for FCM configuration parameters:

To make the picture complete, I need to say a few words about other types of DB2 parallelism. DB2 has an additional option, called intra-partition parallelism, to handle parallel requests inside a single partition, . A special DBM parameter is provided:

# db2 get dbm cfg | grep INTRA
Enable intra-partition parallelism     (INTRA_PARALLEL) = NO

Activating intrapartition parallelism ( INTRA_PARALLEL=YES ) for (DB2
EE), causes
FCM to be started for a single partition database and is used to handle
parallelism for database agents. Without the setting, FCM will not be started for a
single node database, in which case we have following default FCM default values:

Conclusion

The very first task, before starting with any FCM tuning activity, is to understand the internal DB2 working logic and to have an overview of the actual DBM settings. My preferred note of interrogation for any foreign database:

• basic hardware and system configuration
• number of database instances running on the system
• number of database partition servers running on the system
• number of database users
• complexity and type of the applications
• complexity of running queries

» See All Articles by Columnist Marin Komadina