DB2 Instance and Fast Communication Manager

The process
of tuning an ESE DB2 database is almost automatic, at least according to the
DB2 manuals and Web announcements. However, much of this tuning still requires
human intervention. The Fast Communication Manager is one of the components
that need hand tuning. FCM is used to control the information flow between
database partitions as well as to manage optimal performance for shared nothing
architecture. IBM is keeping the details for the FCM interconnection interface
under cover as much as possible, with the intention to make it self managed in
the future. However, version 8.1 still requires some configuration. In this article,
I will explain the global DB2 memory structure and FCM tuning parameters for a SUN
Solaris platform.

This article covers:

  • DB2 Memory
    Model

  • DBM Instance
    Memory Structure

  • Fast
    Communication Manager (FCM)

  • Conclusion

DB2 Memory Model

The DB2 memory model has the following main components:

Database Manager Instance Memory (DBM Shared Memory) is the database manager’s (DBM) allocated
memory, and is used for the DB2 data structures manipulation and instance
activity handling. Information regarding database instance memory handling is
hard to find. DB2 version 7.2 has no ability to control instance memory
allocation, while there exists in DB2 version 8.1 a new DBM configuration
parameter instance_memory for defining suitable instance memory
allocation:

Parameter

Configurable
Online

Automatic

instance_memory

No

Yes

The range
of values for the DBM instance memory allocation are between 32 KB and 2GB or
between 8 and 524 288 4K pages.


# db2 get db cfg | grep DATABASE_MEMORY
Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC

By
default, DB2 will automatically (AUTOMATIC) adjust instance memory allocation to
reflect current resource requirements. The allocated, internally calculated memory
will be acquired on instance activation and freed on instance deactivation.

Database Global Memory (DB Shared Memory) is the database allocated memory
area used by all applications connected to the same database. DB global memory
is allocated on database activation and cleared on database deactivation.
Several shared, dynamically tunable areas build global memory. Included memory areas
are buffer pools, lock list, database and utility heap, package cache, and
catalog cache. Additionally, each database in the instance has a private global
memory block. The minimum reserved, per database shared memory allocation is
defined with the DBM parameter database_memory.

Parameter

Configurable
Online

Automatic

database_memory

No

Yes

The range
of values for the DB database memory allocation are between 0 KB and 16TB or
between 0 and 4 294 967 295 4K pages.

DB2 will
calculate the necessary memory requirements on database activation and
therefore automatically adjust the database_memory parameter.


# db2 get db cfg | grep DATABASE_MEMORY
Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC

The parameter
DATABASE_MEMORY is provided only for DB2 version 8.1 and above.

Application
Memory
is the memory
segment used for internal data exchange between the DB2 database and connected
applications. Application memory is global, shared or private and is allocated
on demand. Application memory size is controlled by the defined maximum
concurrent active applications (maxappls) in the database.


# db2 get db cfg | grep MAXAPPLS
Max number of active applications (MAXAPPLS) = 40 –> version 7.2
Max number of active applications (MAXAPPLS) = AUTOMATIC –> version 8.1

DB2
version 7.2 has 40 as a default number of active applications while version 8.1
defaults MAXAPPLS to AUTOMATIC value.

Agent
Private Memory
is
an application service memory. This memory is allocated by the database agents serving
connected database applications. The agent private memory includes sort heaps,
cursor information and session context area. Common agent’s memory allocation is
limited by lower values of the DB parameters maxappls and maxagents.


# db2 get dbm cfg | grep MAXAGENTS
Max number of existing agents (MAXAGENTS) = 400

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.

Get the Free Newsletter!

Subscribe to Cloud Insider for top news, trends & analysis

Latest Articles