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.
Parameter
|
Configurable
Online
|
Automatic
|
Backbufsz
|
No
|
No
|
restbufsz
|
No
|
No
|
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:
Parameter
|
Configurable
Online
|
Automatic
|
fcm_num_buffers
|
Yes
|
No
|
fcm_num_rqb
|
No (only ver.
7)
|
No
|
fcm_num_connect
|
No ( only ver.
7)
|
No
|
fcm_num_anchors
|
No ( only ver.
7)
|
No
|
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:
Parameter
|
Deault 32bit
(4KB pages)
|
Default 64bit
(4KB pages)
|
Min. 32 bit
(4K pages)
|
Max. 32 bit
(4KB pages)
|
Min. 64 bit
(4KB pages)
|
Max. 64 bit
(4KB pages)
|
fcm_num_buffers
|
4096
|
4096
|
128
|
65 300
|
128
|
524 288
|
fcm_num_rqb
|
2048
|
10,000
|
128
|
120 000
|
128
|
524 288
|
fcm_num_connect
|
1536
|
2048
|
128
|
120 000
|
128
|
524 288
|
fcm_num_anchors
|
1536
|
2048
|
128
|
120 000
|
128
|
524 288
|
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:
Parameter
|
INTRA_PARALLEL=Y
with local clients only (4KB pages)
|
INTRA_PARALLEL=Y
with local and remote clients (4KB pages)
|
fcm_num_buffers
|
512
|
1024
|
fcm_num_rqb
|
256
|
512
|
fcm_num_connect
|
192
|
384
|
fcm_num_anchors
|
192
|
384
|
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