DB2 Instance and Fast Communication Manager – Part 2

Managing DB2 Fast Communication Manager

In the last article, we discovered the DB2
instance memory structure and fast communication manager, together with all of
the DBM parameters influencing memory utilization. In this article we we will
continue along those lines with an inside view of FCM tuning and troubleshooting
techniques for DB2 running on SUN Solaris.

This article covers:

  • Fast Communication
    Manager Memory Structure
  • FCM
    Troubleshooting
  • FCM Tuning
  • Conclusion

Fast
Communication Manager Memory Structure

A DB2 partitioned
database can be installed using one of the tree following configurations:

  1. Single
    database partition configuration (SDP) or Single Logical Node (SLN)

  2. Multiple
    database partition configuration (MDP) or Multiple Logical Nodes (MLN)

  3. Hybrid asymmetric
    system, having a mix of SDP and MDP database partitions

a.) Single database partition configuration has a defined single database partition
per physical host. The global control block for that DB2 instance has the
following FCM structures:

  • FCM Connection
    Entries

  • FCM Message Anchors

  • FCM Request Block

FCM memory structures are separated,
having FCM buffers separated from the rest FCM memory structures. The FCM
buffer Pool is compromised ofthe FCM Control Block and FCM Buffers. Communication
between FCM processes is over UNIX sockets. For each physical node, the memory
structure is identical.

b.) Multiple database partition configuration has several database partitions defined per
physical host. All memory structures for the Fast Communication Manager are
relocated in the FCM Buffer Pool, having the following characteristics:

  • FCM Connection
    Entries /one per partition

  • FCM
    Message Anchors /one per partition

  • FCM
    Request Block /one per partition

  • FCM
    Buffers /global per node

  • FCM
    Control Block /global per node

Inter-partition
communication on the same host occurs through shared memory (direct) and not
over UNIX sockets (FCM deamon). For each physical node, the memory structure is
identical.

c.) Hybrid
system
is very
rare, and it is unusual to find it in practice. Principles discussed for SDP as
well for MDP configuration are also applicable to mixed systems.

Marin Komadina
Marin Komadina
Marin was born June 27, 1968 in Zagreb, Croatia. He graduated in 1993 form The Faculty for Electrotechnology and Computer Sciences, University of Zagreb in Croatia. He started his professional career as a System specialist and DBA for the Croatian company Informatika System. His most important project was the development and implementation of the enterprise, distributed point of sales solution, based on the Oracle technology. In 1999, Marin became the company CTO, where he played an active role in company development and technical orientation. After Informatika System, Marin worked as an IT Manager Assistant for the Austrian international retail company "Segro," on location in Graz (Austria) and Zagreb (Croatia). He was responsible for the company's technical infrastructure and operational support. Segro used IBM technology, OS/400 operating system and DB2 database. In 1998, Marin joined the international telecommunication company VIPNet GSM that was a part of greater concern, Mobilkom Austria& Western Wireless Int. USA. After one year, Marin took over the IT System Manager position, where he managed many multi-platform, telecommunication projects and was leading the IT system department. In 2001, Marin started to work in Germany as a senior system architect. He is currently working for German banks on different banking projects.

Latest Articles