Architecture of DB2 LUW

DB2 LUW:
DB2 LUW architecture is a 3 model design. They are:
1.

Process Model

2.

Memory Model and

3.

Storage model

1. Process Model

Knowledge of the DB2 process model will help you to understand how the database manager and its associated
components interact, and this can help you to troubleshoot problems that might arise.
The process model that is used by all DB2 database servers facilitates communication between database servers and
clients. It also ensures that database applications are isolated from resources, such as database control blocks and
critical database files.
The DB2 database server must perform many different tasks, such as processing database application requests or
ensuring that log records are written out to disk. Each task is typically performed by a separate engine dispatchable
unit (EDU).
There are many advantages to using a multithreaded architecture for the DB2 database server. A new thread
requires less memory and fewer operating system resources than a process, because some operating system
resources can be shared among all threads within the same process. Moreover, on some platforms, the context
switch time for threads is less than that for processes, which can improve performance. Using a threaded model on
all platforms makes the DB2 database server easier to configure, because it is simpler to allocate more EDUs when
needed, and it is possible to dynamically allocate memory that must be shared by multiple EDUs.
For each database being accessed, separate EDUs are started to deal with various database tasks such as
prefetching, communication, and logging. Database agents are a special class of EDU that are created to handle
application requests for a database.
In general, you can rely on the DB2 database server to manage the set of EDUs. However, there are DB2 tools that
look at the EDUs. For example, you can use the db2pd command with the -edus option to list all EDU threads that
are active.
Each client application connection has a single coordinator agent that operates on a database. A coordinator
agent works on behalf of an application, and communicates to other agents using private memory, interprocess
communication (IPC), or remote communication protocols, as needed.
The DB2 architecture provides a firewall so that applications run in a different address space than the DB2 database
server. The firewall protects the database and the database manager from applications, stored procedures, and
user-defined functions (UDFs). The firewall maintains the integrity of the data in the databases, because it prevents
application programming errors from overwriting internal buffers or database manager files. The firewall also
improves reliability, because application errors cannot crash the database manager.
Database server threads and processes
The system controller (db2sysc on UNIX and db2syscs.exe on Windows operating systems) must exist if the database
server is to function. The following threads and processes carry out a variety of tasks:

db2acd, an autonomic computing daemon that hosts the health monitor, automatic maintenance utilities,

and the administrative task scheduler. This process was formerly known as db2hmon.

db2aiothr, manages asynchronous I/O requests for a database partition (UNIX only)

db2alarm, notifies EDUs when their requested timer has expired (UNIX only)

db2cart, for archiving log files (when the userexit database configuration parameter is enabled)

db2disp, the client connection concentrator dispatcher

db2fcms, the fast communications manager sender daemon

db2fcmr, the fast communications manager receiver daemon

db2fmd, the fault monitor daemon

db2fmtlg, for formatting log files (when the logretain database configuration parameter is enabled and

the userexitdatabase configuration parameter is disabled)

db2licc, manages installed DB2 licenses

db2panic, the panic agent, which handles urgent requests after agent limits have been reached

db2pdbc, the parallel system controller, which handles parallel requests from remote database partitions

(used only in a partitioned database environment)

db2resync, the resync agent that scans the global resync list

db2sysc, the main system controller EDU; it handles critical DB2 server events

db2thcln, recycles resources when an EDU terminates (UNIX only)

db2wdog, the watchdog on UNIX and Linux operating systems that handles abnormal terminations

2. Memory Model

DB2 breaks and manages memory in four different memory sets. They are:

Instance shared memory

Database shared memory

Application group shared memory

Agent private memory

Each memory set consists of various memory pools (also referred to as heaps).
db2mtrk - Memory tracker command
Provides complete report of memory status, for instances, databases, agents, and applications. This command
outputs the following memory pool allocation information:

Current size

Maximum size (hard limit)

Largest size (high water mark)

Type (identifier indicating function for which memory will be used)

Agent who allocated pool (only if the pool is private)

Application

The same information is also available from the Snapshot monitor.

>>db2mtrk -i -d -p -m -r interval count -v
i: instance level memory
d: database level memory
p: Private memory
m: maximum value for each pool
r: repeat mode
interval: number of seconds need to wait
count: number of times need to repeat
v: verbos output(view)
Command Parameters
-i
Show instance level memory.
-d
Show database level memory.
-a
Show application memory usage.
-p
Deprecated. Show private memory.
Replaced with -a parameter to show application memory usage.
-m
Show maximum values for each pool.
-w
Show high watermark values for each pool.
-r
Repeat mode
interval
Number of seconds to wait between subsequent calls to the memory tracker (in repeat mode).
count
Number of times to repeat.
-v
Verbose output.
-h
Show help screen. If you specify -h, only the help screen appears. No other information is displayed.

Important dbm cfg for memory model:

We can define the number of databases within an instance by using the paramater "NUMDB"

The dbm cfg parameter which represents instance level memory is "INSTANCE_MEMORY"

The db cfg parameter which represents db level memory is DATABASE_MEMORY

3. Storage model

When you are designing a new database in DB2 on Linux, UNIX, Windows (DB2/LUW) one of the most important
aspects of your design is the layout of your data. It is important to get this right the first time, because changing
layouts is time consuming and difficult. There is a lot of good information on the web already, but I wanted to add
some practical observations that Graham Murphy and I have had in recently implemented or re-designed
systems. This article focuses on OLTP (On-line Transaction Processing) and reporting systems. Data warehouses and
databases with heavy analytical uses are beyond the scope of this document.

Since most of the main concepts are already covered very well by the IBM Database Storage DB2/LUW Best
Practices Guide, I highly recommend that you read it. In this article I will cover some more detailed
recommendations and some alternatives that may be helpful.

File Systems
One of the first items that you need to consider is the number and types of file systems that you need. The reason
that you should work on this first is that it is typically takes a while to get storage allocated especially in large
organizations where there is a separate storage management group. Formal requests need to be well considered by
the omnipotent storage team before then can condescend to bestow disk space to the unwashed masses. Most
organizations now get an allocation from the central SAN system. Storage is usually presented to servers in an
object called a Logical UNit (LUN).
Before making that request it is a good idea to have a discussion with the storage team about how data is stored
and allocated. In some organizations standard sized LUNs are used and in others custom size LUNs can be
ordered. Here are recommendations for the different types of SAN storage
Data on All Disks
In newer disk subsystems there seems to be a trend towards to spreading the storage for LUNS across all disks in the
physical disk device. An example is IBMs XIV storage, but other manufacturers are doing this too. This is the
simplest case for you. If you are getting your LUNs from this type of system and you can get custom sizes then
request 5 LUNs for your database data. There is noting really magic about this number, but it strikes a nice balance
between ease of administration and spreading data. If you want a few more that is fine, but dont go less. If your
organization issues storage in fixed sizes, then order enough LUNs for the amount of space you need. Finally when
LUNs are presented to the operating system then it is a good practice to create one file system on each LUN.
Data on Individual Arrays
On most other types of storage, LUNs are allocated from individual RAID arrays. There is a very good discussion of
how to arrange this storage in the IBM Database Storage DB2/LUW Best Practices Guide so I will not repeat it
here. If possible, you should get one LUN from each RAID array and create one tablespace per LUN.
Unknown
In many organizations the DBAs and others will be deemed unworthy of knowing what is behind the curtain of the
SAN and will not be told. In this case you just have to ask for enough LUNs to meet your needs and hope for the
best. The good news is that this often does provide adequate performance for many small and medium sized
systems. Again you should create one file system per LUN.
The IBM Database Storage DB2/LUW Best Practices Guide goes in depth about types of RAID arrays to create for
DB2 and I highly recommend that you read it. One important thing that I did not see there is how to create your file

systems from LUNs. It is good if you can create one file system per LUN, but sometimes this is not practical for
various reasons. If you find yourself in this situation do not despair. Just remember that when you create the file
system ensure that you stripe the tablespace across the LUNs and do NOT concatenate the LUNS. If you
concatenate the LUNs then as data is added it is only placed in one LUN until it is filled and then moves on to each
subsequent LUN. This is very bad and places the newest and probably hottest data into one or a few LUNS making a
bad hotspot.
Tablespaces
One of the things that Ive been hearing lately is that it is OK to put all of your tables into one or a very few
tablespaces. This is simply NOT TRUE if you need high performance. A good rule of thumb is to put any table with
more than about 5-10 MB of data into its own tablespace. Further it is a good idea to put the indexes for these
tables into an individual tablespaces. That is, you would put all of the indexes for a larger table into a tablespace
created solely for that tables indexes. You can place all of the smaller tables into one tablespace, and the indexes
for all of those tables into another. Graham and I recently worked with a customer who was having performance
problems with their OLTP database who had all of their tables in a single tablespace. Once he broke all of the larger
tables and their indexes into their own tablespaces performance improved dramatically. When he was done this
system had well over 100 tablespaces.
For almost all production data and index tablespaces you should use Large (not Regular) DMS storage. Regular
tablespaces may go away in future releases. Remember with DMS and Automatic Storage you can now specify a
start size and let the tablespace automatically extend as needed.
If you have Large OBject (LOB) data in your database you should design your tablespaces in one of two ways. If your
LOBS are small enough to fit onto the data page with the other data and is frequently accessed, then you should put
the LOBs in line. That means that the LOB column is just part of the row in the data page just like all other
columns. This saves I/O when accessing the LOB data. If the LOBs are large then they should be put into their own
tablespaces using the LONG IN clause in the create table command.

Putting the Tablespaces on File Systems

You should create each tablespace across all data file systems on your server. That is, each tablespace should have
one container (directory) on each data file system. Avoid putting tablespaces in your backup and transaction log file
system. I am aware of two recently redesigned systems that used SAN that stripes each LUN over all disks in the
storage unit. For both of these databases, five data LUNs were created with one file system being placed on each
LUN Both of these systems perform well and there were many tablespaces and every tablespace was striped across
all 5 data file systems. Both of these are high volume OLTP systems with significant reports being created from
them too.

Striping all tablespaces across all file systems can be made easier with Automatic Storage. With automatic storage
you define the available file systems to the database and then DB2 takes care of placing each tablespace across
those file systems as they are created.
Page Size
For OLTP databases use the 4K page size. End of discussion! When using LARGE tablespaces, as should always be
done these days, 4 K tablespaces can grow up to 2 Terabytes. For strictly Reporting or Operational Data Store
databases 8K or 16K pages might be more appropriate so that you get more rows per page. Compression may also
improve performance of reporting databases.

Extent and Prefetch Sizes

The IBM Database Storage DB2/LUW Best Practices Guide has a good description of extent size and provides a well
accepted formula for calculating it. However, there is an interesting alternative that is gaining acceptance in some
quarters for high-volume OLTP databases. This alternative says to use a small extent size of 2 pages. If you need
very high performance in your OLTP database then you may want to experiment with the traditional vs. small extent
size and see what performs better for your work load. I would lean more towards the traditional calculation for
reporting and ODS workloads.
Again the IBM Database Storage DB2/LUW Best Practices Guide has a good description of prefetch size and provides
a well accepted formula for calculating it. Graham has provided me with a formula that can give better performance
is some cases. This alternative formula is:
PREFETCH = Nbr_File_Systems * Extent_Size * Nbr_Channels_to_Disk_System
Where:

NBR_file_Systems is the number of file systems under the tablespace

Extent_Size is the extent size for the tablespace

Nbr_Channels_to_Disk_System is the number of channels to the disk subsystems. Some HBA cards have

multiple channels. The best way to get this figure is to ask your system administrator for the server.