Memory model for DB2 UDB

Brief introduction

Understanding how DB2 uses memory prevents excessive memory allocation and helps to tune memory usage for better performance.

This article will teach you the basics of DB2 memory usage and the concepts of shared memory and private memory. These contents are also applicable to 32-bit and 64-bit systems. Although there are some limitations to the 64-bit system, it is unlikely that these restrictions will be touched for some time in the future. Therefore, we focus on the memory limits that affect 32-bit systems and discuss them in detail.

Let's start with the general DB2 how to use memory, and then discuss how memory management changes with the platform (AIX, Sun, HP, Linux, and Windows) and their impact on DB2. Finally, we will give some meaningful examples of customer situations/problems and their solutions in real life.

The content of this article applies to DB2 version 8.

DB2 Memory Architecture Overview

The DB2 memory structure is illustrated in Figure 1. This memory structure is consistent across all platforms.

Note: In a multiple-partition environment, the following figure applies to each partition in a multiple-partition instance.

Figure 1-DB2 Memory structure

DB2 splits and manages memory within 4 different sets of memory (memory set). These 4 sets of memory are:

Instance shared memory (instance shared memory)

DB Shared memory (database shared memory)

Application group Shared memory (application group shared memory)

Agent private memory (agent private memory)

Each memory set consists of a variety of different memory pools (also known as heaps). Figure 1 also gives the names of each memory pool. For example, Locklist is a memory pool that is part of a database shared memory set. Sortheap is a memory pool that belongs to the proxy private memory set.

We will discuss each memory set in detail.