the evolution of the memory model in ibm db2 for linux

The Evolution of the Memory Model in IBM DB2 for Linux, UNIX and Windows

Applies to: Database and Operating Systems: DB2 on Linux, UNIX and Windows

Summary With the introduction of the Self Tuning Memory Manager in DB2 V9 and the new thread-based architecture in DB2 V9.5 the memory model of DB2 has undergone several modifications. This paper explains how and why the memory model evolved in DB2 V9 and V9.5 compared to DB2 UDB V8. Without explaining all details of the DB2 memory management it concentrates on the basic concepts and terminology and considers especially the most important configuration parameters, their settings and how they changed over time. The focus is on the Linux and UNIX platforms as they are affected by the change to the thread-based architecture in DB2 V9.5.

Author: Johannes Heinrich

Company: SAP AG

Created on: 03 January 2008

Author Bio Johannes Heinrich works as a developer in the porting team for IBM DB2 for Linux, UNIX and Windows at SAP.

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 1


Table of Contents Notation Conventions .........................................................................................................................................3 Memory from the Perspective of the Operating System.....................................................................................3

Physical versus Virtual Memory......................................................................................................................3 Private versus Shared Memory.......................................................................................................................3

Memory Management in DB2 UDB V8...............................................................................................................4 The Process Model .........................................................................................................................................4 The Memory Model .........................................................................................................................................5

Instance-Level Memory................................................................................................................................................5 Database-Level Memory..............................................................................................................................................6 Application-Level Memory............................................................................................................................................6

Summary.........................................................................................................................................................7 Changes to the Memory Model in DB2 V9 .........................................................................................................9

Summary.......................................................................................................................................................10 Memory Management in DB2 V9.5 ..................................................................................................................11

The Process Model .......................................................................................................................................11 The Memory Model .......................................................................................................................................12

Instance-Level Memory..............................................................................................................................................12 Database-Level Memory............................................................................................................................................12 Application-Level Memory..........................................................................................................................................12

Summary.......................................................................................................................................................13 Related Content................................................................................................................................................15 Copyright...........................................................................................................................................................16



Notation Conventions In this paper all DB2 configuration parameters and their values are written in upper case. Also, to clarify if it is a database manager or a database configuration parameter, 'DB' or 'DBM' is added to the end of every parameter as a subscript. To refer, for example, to the INSTANCE_MEMORY database manager configuration parameter INSTANCE_MEMORYDBM is used and to refer to the database configuration parameter DATABASE_MEMORY the term DATABASE_MEMORYDB is used.

Memory from the Perspective of the Operating System We need to start our explanations by reviewing very briefly some concepts of memory management as it is done by the operating system.

Physical versus Virtual Memory

The main task of an operating system is it to manage the available hardware resources as efficiently as possible. Memory is such a resource and it is limited and must satisfy the requests from multiple processes. To accomplish this operating systems never pass the available physical memory segments directly to a process which is running an application. Instead, all applications see virtual memory which is a multiple of the actually existing physical memory. Note that in this scenario a database management system (DBMS) like DB2 is also an 'application' because it is using various processes of the operating system. The mapping between the virtual and the physical memory is done by the operating system with the help of some hardware components (e.g. the Memory Management Unit, MMU).

If the physical memory is too small to accommodate all memory requests from the applications paging occurs which means that some not recently used pages are transferred out of the physical memory to the swap file. Paging is a very costly process and it is therefore highly unwanted in a production database environment. As a consequence, to avoid paging on a database server, the database should be configured in a way that the memory it is using does not exceed the physical memory. In this case - and assuming that no other applications run on the database server - paging does not occur.

Whenever we talk in the following about memory we always talk about virtual memory - if not explicitly stated otherwise. The operating system always provides virtual memory to its applications.

Private versus Shared Memory

With the virtual memory mechanism it is possible to provide every process with its own address space. The memory within a given address space is local or private in the sense that it can be only accessed by the assigned process. On the other hand it is very useful if some memory areas could be seen by all processes. Examples of these memory areas include:

• the kernel of the operating system

• shared libraries

• areas for the communication between the processes (Inter Process Communications, IPC)

This is realized by the operating system by providing areas of shared memory. They are mapped to the address space of multiple processes and special mechanisms are provided so that applications can ensure synchronized access to the shared memory.

It is important to point out that 'private' and 'shared' are memory categories from the perspective of the operating system, not from the DBMS.



Memory Management in DB2 UDB V8

The Process Model

Before we continue and investigate the DB2 UDB V8 memory model it is helpful to have a short look at the DB2 process model.

There is no need to discuss this figure in detail. The important aspect to remember here is that DB2 distributes its tasks to various processes, for example

• a listener process which is responsible for remote communication with the database,

• a number of db2agent and -subagent processes which carry out tasks on behalf of the applications,

• prefetchers and page cleaners which ensure efficient usage of the buffer pools,

• a log writer process which flushes log records from the log buffer to the log files on disk,

• a process that looks for possible deadlocks,

• a process called db2sysc (not shown in the figure above) which acts as the main DB2 system controller and must be always present.

For some process types even a pool of these processes exists (e.g. for the db2agents).

The following is the beginning of a list of the DB2 processes in a typical SAP system running on AIX:



is0016:db2def 2> db2_ps

Node 0

UID PID PPID C STIME TTY TIME CMD

db2def 331844 499776 0 Dec 03 - 0:11 db2sysc 0

db2def 327858 331844 0 Dec 03 - 0:20 db2agent (DEF) 0

db2def 340004 331844 0 Dec 03 - 0:00 db2tcpcm 0

db2def 364632 331844 0 Dec 03 - 6:21 db2stmm (DEF) 0

db2def 385032 331844 0 Dec 03 - 0:07 db2agent (DEF) 0


db2def 409688 331844 0 Dec 03 - 0:00 db2evmgi

db2def 454686 331844 0 Dec 03 - 0:01 db2taskd (DEF) 0


root 462888 331844 0 Dec 03 - 0:00 db2ckpwd 0

db2def 467030 331844 0 Dec 03 - 0:00 db2resync 0

db2def 475150 331844 0 Dec 03 - 0:00 db2licc 0

db2def 479482 331844 0 Dec 03 - 137:34 db2acd 0


db2def 495860 331844 0 Dec 03 - 0:20 db2ipccm 0

db2def 503876 331844 0 Dec 03 - 1:33 db2fmp (C) 0

...

Looking at this process model we come to one important conclusion: since the work that must be accomplished by DB2 is split into multiple processes, there must be a lot of interaction between the processes. From the point of memory management this means that a lot of the memory areas which DB2 uses must be located in shared memory. If we think e.g. on the DB2 buffer pools it is obvious that they must be available to all processes which read and manipulate data.

The Memory Model

The DB2 memory model becomes understandable if we first think about the areas in which DB2 needs to allocate memory. There are three of them:

• Memory needed for the DB2 instance (instance-level memory). • Memory needed for every DB2 database (database-level memory). • Memory needed on behalf of an application (application-level memory).

The following provides an overview over these three areas without going into all details. If a configuration parameter is mentioned in parenthesis this parameter is used to influence the respective memory heap. What exactly is meant by 'influence' depends on the specific parameter - you need to look up the DB2 documentation to find out the details.

Instance-Level Memory

Instance-Level memory is allocated upon start of the instance (db2start) and freed when the instance is stopped. Since this memory area is used by all databases within the instance and all applications of the databases it is completely allocated as shared memory. It is therefore sometimes also called instance-level shared memory or instance shared memory. Instance-level memory contains among other things the following:

• The system monitor heap which holds information used by the snapshot and event monitors (MON_HEAP_SZDBM).

• The audit monitor heap which is used by the audit logging facility (AUDIT_BUF_SZDBM). • In an environment using the database partitioning feature (DPF), the Fast Communication Manager

(FCM ) Buffers (FCM_NUM_BUFFERSDBM) which are used for communication between the partitions. The FCM Buffer handling is different on AIX and Non-AIX systems.



The amount of instance-level memory which can be allocated by the DBMS can be limited with the parameter INSTANCE_MEMORYDBM. If INSTANCE_MEMORYDBM is set to AUTOMATIC DB2 calculates the amount of instance memory needed for the current configuration. If INSTANCE_MEMORYDBM is set to a number, then the larger of INSTANCE_MEMORYDBM or the sum of MON_HEAP_SZDBM, AUDIT_BUF_SZDBM and FCM_NUM_BUFFERSDBM is used as actual limit for the instance memory.

Database-Level Memory

For every database there is one database-level memory set which is used by various database-level tasks like caching database objects, execution of SQL statements, backup and restore, locking etc. Again this memory area must be seen by many different processes and it is therefore allocated as shared memory during explicit or implicit database activation and freed after database deactivation.

Among the consumers of database memory are the following: • The buffer pools. Their size is defined at creation time with the CREATE BUFFERPOOL statement

and can be modified with the ALTER BUFFERPOOL statement. • The database lock list (LOCKLISTDB and MAXLOCKSDB) which holds information about each

currently existing lock. • The shared sort heap (SHEAPTHRES_SHRDB and SORTHEAPDB). If intra-partition parallelism is

switched on via INTRA_PARALLELDBM or the connection concentrator is enabled then DB2 might decide to perform a shared sort. The sort heap for this sort is then allocated on demand in the database-level memory. This memory heap is also used for specific join-, index- and block index operations.

• The package cache (PCKCACHESZDB) which stores already compiled access plans of SQL statements for reuse.

• The utility heap (UTIL_HEAP_SZDB) which is needed by backup and restore operations. • The catalog cache (CATALOGCACHE_SZDB) which stores information about already accessed

objects (object descriptions, privileges etc.) for faster access. • The database heap (DBHEAPDB) which includes the log buffer. All changes to database objects are

written ('logged') first to the log buffer (LOGBUFSZDB) before they are actually applied to the respective data and index pages. Flushing the log buffer is done by DB2. The database heap also contains control block information for tables, indexes, tablespaces and buffer pools.

Like the parameter INSTANCE_MEMORYDBM for instance-level memory the parameter DATABASE_MEMORYDB can be used to limit the database-level memory. Again this parameter can be set to AUTOMATIC so that DB2 calculates an appropriate value upon database activation.

In a production environment the database-level memory takes by far means the largest percentage of physical memory. Within this memory set the buffer pools are the ones that consume the largest percentage.

Application-Level Memory

The memory which is allocated by DB2 to fulfill the request of its applications can be divided into two categories:

• Agent-level private memory is acquired by the db2agents to perform their work. This is private (local) memory and can be seen only by the respective db2agent process.

• Under some circumstances application-level shared memory is also used. This type of memory is allocated by DB2 only if DPF is used, intra-partition parallelism is switched on or the connection concentrator is enabled.

The agent private memory contains the following memory consumers per agent: • The application heap (APPLHEAPSZDB) which holds a copy of the currently executing sections of the

access plan for the associated application. • The sort heap (SORTHEAPDB) which is used for private (local) sort. • The query heap (QUERY_HEAP_SZDBM) which stores information about the SQL statement that is

currently running.



• The statistics heap (STAT_HEAP_SZDB) which is used by the runstats command. • The statement heap (STMTHEAPDB) which is used by the DB2 optimizer as a workspace. • The agent stack (AGENT_STACK_SZDB) which is used as a workspace by each agent to process

SQL statements. • The Java interpreter heap (JAVA_HEAP_SZDBM) which is used by the Java Virtual Machine when it

executes stored procedures or user defined functions written in Java.

Application-level shared memory is used in environments where applications usually require more than one agent to perform its tasks. Here it is desirable that all agents who serve one application can communicate very efficiently with each other. For this purpose DB2 arranges db2agents into application groups and establishes the so-called application group shared memory (APPGROUP_MEM_SZDB). Furthermore, each application within an application group has its own application control heap (APP_CTL_HEAP_SZDB), and a part of the application group shared memory is reserved for the application group shared heap (GROUPHEAP_RATIODB).

Note that for application-level memory - due to its nature - in DB2 UDB Version 8 there is no such superior configuration parameter like INSTANCE_MEMORYDBM for instance-level memory and DATABASE_MEMORYDB for database-level memory which can be used to limit the amount of application-level memory. Instead, a combination of the previously mentioned parameters plus MAXAGENTSDBM can be employed to set a maximum for application-level memory.

Summary

DB2 UDB Version 8 uses various processes to accomplish its tasks. These processes need to communicate with each other and need to do their work in common memory areas. Therefore most of the memory which is allocated by DB2 is shared memory.

The DBMS allocates various memory heaps at three different levels: on instance-, database- and application-level. The instance memory is allocated as shared memory during start of the DB2 instance and determined by INSTANCE_MEMORYDBM. Database memory which is allocated at database activation time is also shared memory and its size is specified with the DATABASE_MEMORYDB configuration parameter. Application-level memory, needed for each application, can be divided in agent private memory (per db2agent) and application-level shared memory (used by all participating agents).

Many of the memory-related configuration parameters must be set to explicit values and tuned manually. The most important parameters can be configured online, i.e. it is not necessary to reactivate the database or restart the database instance after changing them. Recommended parameter settings for SAP systems running with DB2 UDB V8 are provided in SAP note 584952.

The following picture gives a simplified overview about the memory model in DB2 UDB V8. Note that in an environment using DB2's database partitioning feature (DPF) the following figure applies to each partition in the multi-partitioned instance.


https://service.sap.com/sap/support/notes/584952


Instance‐Level Memory INSTANCE_MEMORYDBM

System Monitor Heap (MON_HEAP_SZDBM) once per instance Audit Monitor Heap (AUDIT_BUF_SZDBM)

FCM Buffers (FCM_NUM_BUFFERSDBM)

Database‐Level Memory DATABASE_MEMORYDB

Lock List (LOCKLISTDB and MAXLOCKSDB)

Buffer Pools (4, 8, 16, 32 K) Shared Sort Heap (SHEAPTHRES_SHRDB and

SORTHEAPDB)

once per data‐base

Package Cache (PCKCACHESZDB)

Utility Heap (UTIL_HEAP_SZDB)

Catalog Cache (CATALOGCACHE_SZDB)

Database Heap (DBHEAPDB) Log Buffer (LOGBUFSZDB)

Agent‐Level Private Memory Application‐Level Shared Memory

Sort Heap (SORTHEAPDB and SHEAPTHRESDBM) Application Group

Shared Heap (APPGROUP_MEM_SZDB, GROUP_HEAP_RATIONDB)

Application Heap (APPLHEAPSZDB) once per application group

once per agent

Query Heap (QUERY_HEAP_SZDBM)

Statement Heap (STMTHEAPDB)

Application Control Heap (APP_CTL_HEAP_SZDB) one per application

Statistics Heap (STAT_HEAP_SZDB)

Agent Stack (AGENT_STACK_SZDB)

Java Interpreter Heap (JAVA_HEAP_SZDBM)



Changes to the Memory Model in DB2 V9 The most prominent advancement in DB2 V9 regarding memory management was the introduction of the 'Self Tuning Memory Manager' (STMM).

STMM can determine optimal values for • The buffer pools • The package cache (PCKCACHESZDB) • The database lock list (LOCKLISTDB and MAXLOCKSDB) • The shared sort heap (SHEAPTHRES_SHRDB and SORTHEAPDB)

STMM adapts these values according to the current workload (adaptive tuning). All of these consumers are part of the database-level shared memory. STMM can trade portions of memory between all consumers which are enabled for self-tuning so that the DATABASE_MEMORYDB is used as efficient as possible. This is shown in the following picture.

In addition to that, on some platforms (namely AIX and Windows) DATABASE_MEMORYDB itself can be tuned by STMM so that it allocates more memory from the OS if this is needed (and there is more free physical memory) and returns this memory back if it is no longer needed by DB2 or if the OS runs low on free physical memory.

To enable STMM, SELF_TUNING_MEMDB must be set to ON and at least two of the memory consumers mentioned above to AUTOMATIC. If DATABASE_MEMORYDB is set to a numeric value it is enough if one of the memory consumers mentioned above is set to AUTOMATIC (in this case the free memory in the database-level memory set is considered as the second parameter to tune). The buffer pools can be enabled for self tuning by STMM with the command ALTER BUFFERPOOL ... SIZE AUTOMATIC. Regarding DATABASE_MEMORYDB, the semantics of the parameter value AUTOMATIC has changed from DB2 UDB V8 to DB2 V9. Setting DATABASE_MEMORYDB to AUTOMATIC in DB2 V9 means that this parameter is also enabled for STMM (only possible on AIX and Windows). To retain the old DB2 UDB V8 behavior in DB2 V9 this configuration parameter must be set to COMPUTED.



More details about STMM can be found in 'The Self-Tuning Memory Manager (STMM): A Technical White Paper'.

Another important change in DB2 V9 is that now sort memory consumers can run in shared memory all the time, regardless of the INTRA_PARALLELDBM setting or the enabling of the connection concentrator. Placing all sort activities in the database-level memory is in fact the recommended behavior; it can be achieved by setting SHEAPTHRESDBM to 0.

Summary

With DB2 V9 a self tuning memory manager (STMM) was introduced which determines automatically and based on the current workload optimal values for the consumers of the database-level shared memory. The size of the database-level shared memory itself can also be tuned by STMM on the AIX and Windows platform. To enable STMM, the respective configuration parameters are set to AUTOMATIC and SELF_TUNING_MEMDB must be set to ON. In case of DATABASE_MEMORYDB the value of AUTOMATIC as known in DB2 UDB V8 was replaced by the value COMPUTED.

All sort activities can now take place in the database-level memory.

Recommended parameter settings for SAP systems running with DB2 V9 are provided in SAP note 899322. In this note two sets of parameter settings are described: one set for systems where STMM is enabled and another one for systems where STMM is disabled.


ftp://ftp.software.ibm.com/software/data/pubs/papers/stmm.pdf




Memory Management in DB2 V9.5

The Process Model

In DB2 V9.5 a new process model was introduced. Instead of using several processes to do all the work, everything is now one process. What used to be a process in DB2 9 became a thread in DB2 V9.5.

In other words, the DB2 engine is now thread-based on all UNIX and Linux platforms (it was thread-based on Windows before). If we look on an AIX based system with DB2 V9.5 we now get, for example, the following as process list:

is0020:db2mi5 1> db2_ps

Node 0

UID PID PPID C STIME TTY TIME CMD

db2mi5 323822 397342 0 Dec 17 - 88:36 db2sysc 0

root 327732 323822 0 Dec 17 - 0:00 db2ckpwd 0

root 401520 323822 0 Dec 17 - 0:00 db2ckpwd 0

root 462900 323822 0 Dec 17 - 0:00 db2ckpwd 0

Everything is now contained in the db2sysc process. Some other processes like db2ckpwd (for user authentication), db2fmp (for executing fenced mode stored procedures and UDFs), db2wdog (for handling abnormal terminations) or db2vend (for backups to TSM) may appear, but the complete DB2 engine runs in just one process and therefore uses one address space. This leads to simplifications in the memory model.




The Memory Model

Instance-Level Memory

The meaning of the configuration parameter INSTANCE_MEMORYDBM has changed completely in DB2 V9.5. This parameter now specifies the maximum amount of memory that DB2 can allocate - including database-level memory and application-level memory. In other words, there is now only one parameter which determines how much memory DB2 can consume. Note especially that INSTANCE_MEMORYDBM is not pre-allocated by DB2, it just gives an upper limit up to which DB2 can take memory if there is a need for this. If INSTANCE_MEMORYDBM is set to AUTOMATIC, DB2 calculates an actual value at instance start (db2start) by taking 75 to 95 percent of the available physical memory. If DB2 runs in a partitioned environment, INSTANCE_MEMORYDBM is specified and calculated on a partition base (in other words, INSTANCE_MEMORY is calculated by taking the 75 to 95 percent of the physical available memory divided by the number of local partitions). The AUTOMATIC setting is intended for dedicated database servers; if other applications (e.g. SAP instances) run on the database server it makes sense to set INSTANCE_MEMORYDBM to a specific value. The value of INSTANCE_MEMORYDBM does not provide any information about the actual memory consumption of DB2. To monitor actual memory consumption the new user defined function (UDF) ADMIN_GET_DBP_MEM_USAGE was introduced.

Database-Level Memory

DATABASE_MEMORYDB can now be set to AUTOMATIC and thereby enabled for self-tuning with STMM on all UNIX platforms1. If DATABASE_MEMORYDB is set to AUTOMATIC the initial value for DATABASE_MEMORYDB is calculated by DB2 as a function of the sum of the configured size of all buffer pools and heaps defined for the database.

Another improvement in DB2 9.5 is that the parameter DBHEAPDB can now be set to AUTOMATIC meaning that the database heap can grow as needed up to the limit that is set by DATABASE_MEMORYDB. Note that this does not mean that DBHEAPDB is controlled by STMM2.

Application-Level Memory

Most changes in the memory model in DB2 V9.5 are related to application-level memory. As a consequence of the new threaded model the distinction between application-level shared memory and agent private memory is no longer made. Instead, a new configuration parameter APPL_MEMORYDB is introduced which can be used to limit the maximum amount of application-level memory allocated by all db2agents. Note that the sum of DATABASE_MEMORYDB and APPL_MEMORYDB must always be in the range of INSTANCE_MEMORYDBM. Again APPL_MEMORYDB can be set to AUTOMATIC which means that there is a minimal allocation of application memory at database activation time. After that the allocated amount of application-level memory increases and decreases on demand.

Further changes to application-level memory in DB2 V9.5 include: • The meaning of APPLHEAPSZDB has changed. In the DB2 releases prior to DB2 V9.5 this

configuration parameter referred to the application heap per db2agent. Now there is one application heap per database application, not per db2agent. The application heap is now shared by all db2agents working for an application. It is expected that this will lead to memory savings. The value of APPLHEAPSZDB can now be set to AUTOMATIC which allows the application heap to grow until the APPL_MEMORYDB limit is reached.

• Additionally to APPLHEAPSZDB the configuration parameter STMTHEAPDB and STAT_HEAP_SZDB can now be also set to AUTOMATIC meaning that they can also grow up to the limit defined by APPL_MEMORYDB.

1 Only on some older Linux kernels either INSTANCE_MEMORYDBM or DATABASE_MEMORYDB can be set to AUTOMATIC. 2 However, if STMM is enabled and the database heap grows and consumes some of the free database-level shared memory, STMM reacts by shrinking one of the heaps it is tuning. This can be seen as indirect tuning and works in the same way for some other memory heaps.


• The concept of multiple application groups is no longer needed. Now there will be only a single application group which can grow until the APPL_MEMORYDB limit is reached. Consequently the configuration parameters APPGROUP_MEM_SZDB, APP_CTL_HEAP_SZDB and GROUPHEAP_RATIODB are deprecated; they will be ignored by DB2. This will again simplify the memory configuration

Summary

DB2 V9.5 is based on a new threaded architecture on all UNIX/Linux platforms. This leads to great simplifications in the memory model. The memory which can be allocated by DB2 is controlled by one single parameter (INSTANCE_MEMORYDBM). There are two other important superior parameters (DATABASE_MEMORYDB and APPL_MEMORYDB) which control the allocation of database-level memory and application-level memory within the limits provided by INSTANCE_MEMORYDBM. Nearly all other memory configuration parameters for the different memory heaps used by DB2 now support an AUTOMATIC setting. It is still possible to limit particular memory areas in DB2 to a specific size.

The meaning of the configuration parameters INSTANCE_MEMORYDBM and APPLHEAPSZDB has changed in DB2 V9.5.

Recommended configuration parameter settings for SAP system running with DB2 V9.5 can be found in SAP note 1086310.

The following picture gives an overview about the memory model in DB2 V9.5. Memory areas which can be enabled for tuning by the Self Tuning Memory Manager are marked with (STMM).




maximal amount of memory per database partition INSTANCE_MEMORYDBM

System Monitor Heap (MON_HEAP_SZDBM)

Audit Monitor Heap (AUDIT_BUF_SZDBM)

FCM Buffers (FCM_NUM_BUFFERSDBM)

Database‐Level Memory DATABASE_MEMORYDB (STMM)

Lock List (LOCKLISTDB and MAXLOCKSDB) (STMM)

Buffer Pools (4, 8, 16, 32 K) (STMM)

Shared Sort Heap (SHEAPTHRES_SHRDB and SORTHEAPDB) (STMM)

once per data‐base

Package Cache (PCKCACHESZDB) (STMM)

Utility Heap (UTIL_HEAP_SZDB)

Catalog Cache (CATALOGCACHE_SZDB) once per instance Database Heap (DBHEAPDB)

Log Buffer (LOGBUFSZDB)

Application‐Level Memory APPL_MEMORYDB

Application Heap (APPLHEAPSZDB)

Statement Heap (STMTHEAPDB)

Statistics Heap (STAT_HEAP_SZDB)

Agent Stack (AGENT_STACK_SZDB)

for all agents

per agent/on request

Java Interpreter Heap (JAVA_HEAP_SZDBM)



Related Content • Book 'Understanding DB2' by Raul F. Chong, Clara Liu, Sylvia F. Qi, Dwaine R. Snow, IBM Press

2005

• The DB2 UDB memory model, article at IBM developerWorks

• The Self-Tuning Memory Manager (STMM): A Technical White Paper

• IBM DB2 V9.5 Information Center

• IBM DB2 V9 Information Center

• IBM DB2 UDB Version 8 Information Center

• SAP on DB2 for Linux, UNIX and Windows in the SAP Developer Network (SDN)


http://www.ibm.com/developerworks/db2/library/techarticle/dm-0406qi/


http://publib.boulder.ibm.com/infocenter/db2luw/v9r5

http://publib.boulder.ibm.com/infocenter/db2luw/v9

http://publib.boulder.ibm.com/infocenter/db2luw/v8

https://www.sdn.sap.com/irj/sdn/db6



Copyright © 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

the evolution of the memory model in ibm db2 for linux

Documents