DB2 v9 Basic Architecture PDF

®
Information Management
DB2 Technical Workshop

DB2 Basic Architecture
Business Partner Technical Enablement

IBM Software Group
© 2006 IBM Corporation
It is important to understand the basic DB2 architecture and how it “operates internally”. While DB2 is
similar to other relational database systems, there are certain fundamental differences that you should be
aware. The terminology used to describe the various features and objects in DB2 may sound similar to the
terminology used by other databases, however it may refer to a completely different concept. It is therefore
important to pay close attention to what we are about to discuss. In this module, we introduce some of the
DB2 tools and utilities, the DB2 process model, and the concept of instances and databases.
DB2 GUI Tools
Control Center Configuration Assistant

Central point of administration Tool to configure the client
A light-weight version of the Control Center
Command Editor
Replication Center
GUI wrapper for command line processor (CLP)
A GUI tool to set up and administer a replication
Journal environment and to run the Capture and Apply
programs
Central point for logging DB2 activities
Wizards
License Center Create database
Central point of DB2 license management Create database objects (tables, views, etc.)
Task Center Generate DDL
Show SQL / Show Command, etc.
Central point for scheduling database jobs
Information Center
Health Center Find information about tasks, reference material,
Central point for DB2 health monitoring troubleshooting, sample programs, and related Web
Memory Visualizer sites.
Performance Tools Developer Workbench

New development environment for building stored
Storage Management procedures, user-definde functions, and structured
Self-Tuning Memory Manager data types.
Also useful for creating XQuery statements,
Visual Explain registering XML schemas, annotating XML Schema
Event Monitors documents for shredding, SQLJ development, etc.
Memory Visualizer Data Warehouse Manager
Event Analyser Includes reporting, online analytical processing, and
data mining applications.
Indoublt transaction Manager
DB2 ships with both graphical user interface and command line tools, some of which are shown here.
The most important tool you will probably use is Control Center, which is the central point of
administration in DB2. From Control Center, you can perform administrative tasks such as taking a
backup, creating a new table, and collecting database statistics. When you have a moment, we highly
recommended taking a closer look at the all of the graphical tools shown here as they can significantly
increase your productivity and lessen the burden of memorizing new command syntax. The majority of
the functionality available in the GUI tools is also available from the command line. The command line
syntax typically gives you more freedom to customize the target operation in more detail.
DB2 Command Line Processor (CLP)

To access it on Windows, click on the DB2 Command Window or Command
Line Processor icons, on Linux and UNIX platforms, log into the system as the
instance owner and type db2 at the command prompt.
3 modes of operation
– Interactive mode
– an input prompt appears: db2 =>
db2 => connect to sample
– Command line mode
– invoke the interpreter by prefacing commands and SQL with 'db2'
db2 connect to sample
db2 "select * from employee"
– File input mode:
– execute CLP command with db2 -f
db2 -tf createtab.db2
The command line interface to DB2 is known as the Command Line Processor, or CLP. To open CLP from
Windows, navigate to Start>Program Files>IBM DB2>Command Line Tools>DB2 Command Line
Processor. On Linux and UNIX systems, it can be launched by logging on as the instance owner, and typing
“db2” at the operating systems’ command prompt.
CLP can be run in three different modes:

1. In the first, known as “Interactive Mode”, CLP’s default prompt (db2=>) will appear on the screen awaiting
input. In this mode, you can enter any valid DB2 command such as “CONNECT TO SAMPLE” or “SELECT *
FROM SALES” and subsequently execute the command by pressing the enter key.
2. The second, is known as “Command Line Mode”, which allows you to interface directly with DB2 from the
operating system prompt by prefixing all database instructions with “db2” so that they are not confused with
an operating system command. You may need to put quotation marks around your command or statement
so the operating system command interpreter ignores any special characters you might be using, such as the
asterisk (*).
It should be noted that on Windows platforms, if you want to run to CLP in command line mode, you must
issue the commands within a DB2 Command Window. A DB2 Command Window looks identical to a
“Windows Operating System” Command Prompt, except that the DB2 environment has been initialized. You
can open one by going to Start>Program Files>IBM DB2>Command Line Tools>DB2 Command Window.
If you try to enter DB2 commands from a “Windows Operating System” Command Prompt, you will get an
error message that says “Command Line Not Initialized”.
3. In the third mode, file input, you can direct the utility to a file containing a list of commands you want to
submit. When using file input mode, prefix the ‘db2” command is followed by a “–f” and the name of the file.
By default, DB2 expects each command to be terminated with a semi-colon (;) although this can be changed.
Again, on Windows platforms, if you want to run to the Command Line Processor in file input mode, you must
issue the commands from a DB2 Command Window.
DB2 Command Line Processor (CLP)... continued
To end interactive or command line mode and terminate the DB2

backend process (db2bp):
db2=> terminate
db2 terminate
To end the interactive mode, enter

db2=> quit
To execute OS commands, enter !<OS command>

db2=> !dir
When you connect to a database from the Command Line Processor, you will notice that a new
process, called db2bp is started. This is a background process that maintains the connection to the
database. To terminate the database connection and kill this background process, use the terminate
command.
To exit the Command Line Processor’s interactive mode, enter quit. This returns you to a standard
operating system command prompt.
While you are in interactive mode, you can issue operating system commands, such as “ls” or “dir”, if
you prefix them with an exclamation mark (!).
CLP Command Line Options
LIST COMMAND OPTIONS

No. of retries to connect to backend (DB2BQTRY) = 60
Request queue wait time (seconds) (DB2RQTIME) = 5
Input queue wait time (seconds) (DB2IQTIME) = 5
Command options (DB2OPTIONS) =
Option Description Current Setting
------ ---------------------------------------- ---------------
-a Display SQLCA OFF
-c Auto-Commit ON
-e Display SQLCODE/SQLSTATE OFF
-f Read from input file OFF
-l Log commands in history file OFF
-n Remove new line character OFF
-o Display output ON
-p Display interactive input prompt ON
-r Save output to report file OFF
-s Stop execution on command error OFF
-t Set statement termination character OFF
-v Echo current command OFF
-w Display FETCH/SELECT warning messages ON
-x Suppress printing of column headings OFF
-z Save all output to output file OFF
The DB2 Command Line Processor has several options that can be changed, such as whether auto-
commit should be turned on, whether the current command should be echoed in the output, and
whether the contents of the SQLCA should be displayed in the output. To view the current values of
these options, enter the command: “LIST COMMAND OPTIONS”.
The resulting output shows each of the different options and their current values. The “Option” column
of the output shows the identifier that should be used to toggle the value the parameter. Note that on
Linux and UNIX platforms, these identifiers are case sensitive. The “Current Settings” column shows a
parameter value’s current status. On the next slide, we see these values can be changed.
CLP Command Line Options… continued

To change default command options
e.g. set environment variable passed to CLP
db2set db2options=+c (to turn auto commit off)
To change command option for the current session
e.g. to save output to file:
UPDATE COMMAND OPTIONS USING z ON output.txt
Access to history of commands (when you are in Interactive mode):
db2=> history (or H, h)
db2=> runcmd # (or R, r)
Utilize a text editor (when you are in Interactive mode):
db2=> edit (or E, e)
Also see:
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0503melnyk/
Let’s look at some typical examples of changing CLP options.
To change the value of these options so that they affect all future sessions, you can update a DB2
registry variable called “db2options”. For example, if you wanted to turn the auto-commit option off,
you would set the “db2options” registry variable using the following command: “db2set
DB2OPTIONS=+c”. The plus (+) and minus(-) signs are used to toggle the values of the parameters.
Be careful not to leave any spaces before or after the equal sign (=) in the db2set command. This is a
very common mistake that will not update the registry variable correctly.
If you only want to change an option value for the current session, you can use the “UPDATE
COMMAND OPTIONS” command. When using this command, you must specify the parameter and
the value ON or OFF, depending on how you want it’s value to be set. In the above example, we
update the “z” option, which determines whether output is logged. Since the “z” option logs all the
output in a file, we must also specify the file name the output should be logged in.
To see a history of previous commands you have issued in your session, you can enter “history” or
just “h” for short. Listed with each previous command is a line number. You can use this number to
reference and run a previous command again. To do that, use the “runcmd” command, and provide
the reference number from the “history” list output.
To edit the previous command submitted while in Interactive mode, use the “edit” or “e” command.
This opens the command for editing. You also have the option to run the revised command when you
are finished editing.
DB2 Command Editor

A GUI wrapper for command line processor (CLP)
Command results are displayed. SQL

results are returned on the Query Results
tab. The access plan appears in graphical
form on the Access Plan tab.
For those who prefer a GUI interface to the database, DB2 has Command Editor.
Command Editor can essentially be thought of as a GUI wrapper for CLP. It has the traditional advantages of a
GUI interface, such as toolbar buttons, simple editing, and the ability to save or print files. You can use the
Command Editor to generate, edit and execute SQL statements and DB2 commands; work with the resulting
output; and view a graphical representation of the access plan for explained SQL statements.
The Command Editor can be launched in multiple ways. It can be opened in a separate window by clicking it’s
icon on the IBM DB2 Windows group for Command Tools, or from within Control Center via the drop down
“Tools” menu as well as embedded in a Control Center window by a right-click on any “query-able” object and
selecting the “Query” option. [DEMO]. If you choose, the executable can be run directly from a operating
system command prompt by typing “db2ce”.
The Command Editor appears as a three-tab window:
On the “Commands” tab, you enter DB2 commands and SQL statements. Command results are displayed in the
bottom output area. The results of multiple SQL queries or queries executed as part of a script are also
displayed in the output area. The result set of a single SQL query is returned on the “Query Results” tab.
You can also generate the access plan for SQL statements in the “Commands” tab. Access plans appears in
graphical form on the “Access Plan” tab.
The “Query Results” tab contains the result set of a single SQL query. Results are displayed in an editable table.
The “Access Plan” tab shows a graphical representation of the access plan for explainable SQL statements (for
example, SELECT, INSERT, and UPDATE statements). An access plan shows how DB2 will fetch the data
from disk and return a result set, while also showing the associated cost.
The DB2 Server Picture
Admin Server My Server

(DAS)
instance instance
1 2
Database 1 Database 2 Database 1
One physical machine has: Each instance (database manager):

• One Administration Server • Is a logical server context
• One or multiple instances • Can have one or more databases
To help us understand the DB2 Server let’s picture a typical DB2 Environment.
The outer blue rectangle depicts the physical hardware of a server.
Every system with DB2 installed has one background process known as the DB2 Administration
Server, or “DAS”. The main purpose of DAS is to provide remote administration support. It is
required if you want to use many of the functions of the GUI client tools. For the most part, simply
being aware of its existence is sufficient. You can let it run in the background and forget about it. If
you are having problems administering the server from a client, ensure that the DAS process is
running. Each physical server has only one DAS process.
DB2 also has the concept of an instance. An instance is the set of processes, disk and memory
allocations which provide database services. You can also think of an instance as a container for
databases. One instance can be used to provide services to one or more databases. A single
machine can have one or more instances. Each instance is independent of other instances, and has
it’s own set of configurable parameters.
A database is the set of files which contain the actual data. You can create multiple databases inside
of an instance. Each database is independent and does not share it’s configuration, system catalogs
or transaction logging mechanism. You cannot query across multiple databases, unless you utilize a
DB2 technique known as “Federation”.
By default the DB2 installation will automatically create the DAS process and a default instance. No
database is created by default.
We will describe instances and databases in more detail later in the Workshop.
DB2 Administration Server Process (DAS)
Stopping and starting

db2admin {stop | start} DB2 Administration Server
A background process to support instance administration

dasusr1 on UNIX (default)
DB2DAS service on Windows (default)
Only one DAS process per server machine
Required for:
Network database discovery
Remote administration
Tools Catalog task scheduling
The DB2 Administration Server should always be running. However, you can manually stop and start
it from a DB2 command window by using the db2admin command.
Note that on UNIX and Linux platforms, you need to log onto the system as the DAS owner in order to
have administration privilege to stop and start the process.
In addition to providing remote administration support, the DAS is also used to carry out user-defined
automated tasks such as backups and statistics collection. It is also used to support network database
discovery in which DB2 clients can broadcast a message over the network to "discover" what
databases exist. Servers without a running DAS process cannot respond to such broadcasts.
DB2 Admin Server (Windows)
The DAS process can also be stopped and started from the services panel in Windows
DAS
10
The DAS process on Windows can also be stopped and started from the Windows services panel.
Right click on the DAS process, called “DB2DAS00” and select “Stop”. To start it, right-click on it again
and choose “Start”.
DB2 Profile Registry
Host
machine
Database
Manager
Instance
configuration
DBM CFG
Database
Database
Configuration
DB2 Registry DB CFG
new features, platform
specific optimizations
special optimizations
11
The DB2 Environment has a set of configurable items stored in what is know as the DB2 Profile
Registry.
This should not to be confused with the Windows’ Registry. DB2’s Profile Registry could be described
as a set of persistent variables which retain their settings regardless of system reboots and database
restarts. Registry settings are used to control database server features as well as platform-specific
and other special optimizations.
DB2 Profile Registry (db2set)

list variables set
for instance db2set
list all currently
db2set -all set variables
list all available db2set -lr
variables for set a registry
platform db2set <r>=<value> variable
A place to specify environment or platform specific settings

ƒ e.g. settings for RAID, optimizer paths not yet fully integrated, communication
protocols, environment specific performance enhancements
Settings can be applied to various levels

ƒ Environment
ƒ Instance
ƒ Global (all instances)
12
DB2 Profile Registry settings are different than the Database Manager and Database configuration
parameters. DBM and DB Config parameters are platform independent and are consistent across
Windows and UNIX platforms. There are often platform specific optimizations or advanced features
which the DB2 server can leverage and they are typically configured and activated using the Registry.
To view the current registry settings, use the “db2set” command. There are additional flags you can
add to that command to filter the output. For example, the “-all” flag shows all the registry variables that
are currently set. The “-lr” flag lists every available registry variable that can be set for the current
platform.
To set or change one of the registry parameters, use the “db2set” command, followed by the
parameter name, the equal sign (=), then the new value. Ensure that you do not leave a space on
either side of the equal sign or else your change will not take effect.
Registry variables can be set and applied at various levels. You can set them globally so that they
apply to all instances. They can be set for a specific instance. Or they can be set at an environment
level, which means that they are set outside of DB2 using the “set” command in Windows, or the
“export” command in Linux and UNIX.
A commonly set registry variable is DB2COMM. This variable tells DB2 what communication protocols
it should be using to listen for connections. To enable DB2 to listen for TCP/IP connections, you would
issue the command: “db2set DB2COMM=tcpip”. This is done by default during the DB2 installation
process if the installer detects a TCP/IP configuration. To unset a registry variable, set it, but do not
specify a value on the right side of the equals sign.
With very few exceptions, the instance must be restarted before the Registry setting takes effect.
Instance Concepts
An instance is also known as a Database Manager (DBM)
Manages the system resources assigned to it
Can be independently stopped or started
Has its own set of processes
Has its own configuration file (DBM CFG)
security plan
performance
communications
Example:
One instance for development, another for QA testing.
Both instances are fully independent.
13
An instance is a logical server environment needed to create and work with databases. An instance is
also frequently referred to as a database manager, or DBM.
Instances are a collection of processes which provide access to database(s). If you have more than
one instance created on a machine, each instance acts as an independent server environment which
can be stopped and started without affecting other instances.
Each instance also has its own configuration file, which is called the Database Manager Configuration
file, or “DBM CFG”. In DB2, various settings are controlled at the instance level, such as security,
communications, and certain performance attributes. All databases contained in the instance inherit all
of the instance’s configuration and share the instance’s resources.
You might be asking yourself why you would want to have more than one instance on your server.
There are different reasons for doing this. For example, you might want to have one instance set up for
your developers, and another instance set up for your testers. That way, if the testers crash their
instance while they are doing testing work, it will not affect the developers’ instance. Another reason
might be that you don’t want two databases to inherit the same instance configuration settings. A good
example of this is the TCP/IP port that applications will be using to connect to the database. This port
is defined at the instance level, meaning that two databases contained in the same instance will both
be listening for connections on the same port. If you wanted the databases to listen for connections on
different ports, you would need to put them in their own instances and set the correct port number for
each.
Database Manager Configuration File (DBM CFG)
Host
machine
Database
Manager Instance
configuration
DBM CFG
Database
Database
Configuration
DB2 Registry DB CFG

14
This diagram depicts the scope of the Database Manager configuration. If you created two instances
on the same machine, each would have its own set of DBM CFG parameters that could be configured.
It should be noted that while the configuration of the Database Manager affects all databases within
the instance they do not establish a hierarchy of parameters, as we shall see, DBM CFG parameters
are unique instance-only settings.
Instance - Stopping and Starting

It is sometimes necessary to stop and restart an instance
example: after changing a non-dynamic parameter in the DBM CFG
db2stop [force]
or
db2start
15
If you change a non-dynamic instance configuration parameter, you have to stop and restart the
instance for the change to take effect.
From the command line, this can be done using the “db2stop” and “db2start” commands.
Before an instance can be stopped, all applications must disconnect. If you want to stop the instance
immediately, forcing off all applications thus terminating their associated processes, you can use the
”db2stop force” command.
An instance can also be stopped in the Control Center by right-clicking on the instance object and
selecting either Stop or Start.
DBM CFG
show get dbm cfg [show detail]
parameters update
update dbm cfg using <p> <v> parameters
Many parameters are dynamic (take effect immediately).
Changes to other parameters may require an instance

restart.
16
The Database Manager configuration can be viewed or modified using the command line, or through
Control Center
From the command line, you can enter the “GET DBM CFG” command to view the current parameter
values. Adding the “SHOW DETAIL” keywords to the command shows both the current and delayed
value of the parameters. The delayed value is the value that will take effect after stopping, then re-
starting the instance.
To update a parameter, you can use the “UPDATE DBM CFG” command. The syntax of this
command is shown on the slide. Substitute the actual parameter name for <p> and the new value for
<v>. For example, to update the port number that databases will listen to connections on, to port
50009, you would use the command: “update dbm cfg using svcename 50009”.
Many parameters can be changed dynamically and will take effect immediately. However, if a
parameter is not dynamic, the instance must be restarted for the change to take effect. To see if a
changed parameter was dynamic, use the “get dbm cfg show detail” command and check if the
delayed value matches the current value. If they do not match, an instance restart is required for the
new value to take effect.
To view or update the database manager configuration from Control Center, right-click the target
instance in the object tree pane and select Configure Parameters”. A list of configurable parameters
will then be shown in a new window. Click the box with the three dots (…) beside the parameter to
update the value.
Databases Concepts
A collection of tables and related objects
Each database includes

system catalog tables (database meta data)
a database configuration file (DB CFG)
a recovery log
Databases are isolated from each other (object independent)
17
A database is a collection of tables (including the data) and related objects such as indexes, views,
triggers, functions, and stored procedures. Each database also has its own system catalog tables
which contain meta data that describes the content of the database. A database also has its own
configuration file and recovery log.
Databases are isolated and independent from each other to the extent of database objects and data.
For example, two databases do not share the same system catalog tables or recovery log. However, if
the databases exist in the same instance, they share the same instance processes.
Database Configuration File (DB CFG)
Host
machine
Database
Manager Instance
configuration
DBM CFG
Database
Database
Configuration
DB2 Registry DB CFG

18
This diagram depicts the scope of the database configuration. Each database defined in an instance
will have its own configuration file. For example, if there are two databases in an instance, there will
be one database manager configuration file for the instance parameter settings and two database
configuration files, one for each database.
DB CFG from Command Line

show
parameters get db cfg for <dbname> [show detail]
update update db cfg for <dbname> using <p> <v>
parameters
Parameters include:
ƒ location of database logs
ƒ defaults for query optimization
ƒ size of memory for lock management
ƒ etc.
Many parameters are dynamic. Others may require that all applications
disconnect.
Non-dynamic changes to take effect after all applications disconnect and
the first application re-connects
19
Database Configuration parameters control things such as the placement of log files, defaults for query
optimization, and the amount of memory allocated for the lock list or sorting.
The database configuration file, or DB CFG, is viewed by using the “GET DB CFG FOR” command.
For example, to view the database configuration for a database named sample, you would use the
command “get db cfg for sample”.
To update a parameter, use the “UPDATE DB CFG FOR” command. For example, to increase the
amount of memory used for locking, you would update the value of the LOCKLIST parameter to 2000
4K pages using the command: “UPDATE DB CFG FOR SAMPLE USING LOCKLIST 2000”.
Many parameters are dynamic and will take effect immediately. If a parameter is not dynamic, the
database must be restarted for the change to take effect. The instance does not need to be stopped, it
can remain running, but the database will need all applications to disconnect and all database
processes be deactivated. If the database was previously activated with the ACTIVATE DATABASE
command, the DEACTIVATE DATABASE command must be issued. Otherwise, a database will no
longer be active once the last application is terminated.
Once again, to see if a changed parameter was dynamic, use the optional keywords “SHOW DETAIL”
when displaying the db cfg parameters and check if the delayed value matches the current value.
DB CFG from Control Center
20
To view or update the configuration from the Control Center: right-click the target database in the
object tree and select “Configuration Parameters”. A list of parameters will then be shown in a new
window. Click the box with the three dots (…) beside the parameter to update it’s value.
In the example shown here, we right-clicked on an database called “SAMPLE” and selected the
“Configure Parameters” option.
You should also take note of the menu item "Configuration Advisor". This menu item helps you
automatically configure a database by guiding you through a Wizard that uses an interview-style to ask
questions about your database and it’s workload. Configuration Advisor will then use your answers to
compute parameter values and provide recommendations on their setting.
AUTOMATIC DBM and DB Configuration Parameters
Some DBM and DB configuration parameters support the value

AUTOMATIC. If set to automatic, DB2 will automatically adjust the
parameter to reflect current resource requirements.
DBM configuration parameter that supports AUTOMATIC:

instance_memory - Amount of memory reserved for the instance
DB configuration parameter that supports AUTOMATIC:

database_memory - Size of database shared memory
maxappls - Maximum number of active applications
21
Certain database manager and database configuration parameters accept a value of “AUTOMATIC”.
If you set a parameter to this value, DB2 automatically calculates the optimal value to use, based on
current resource usage.
The database manager parameter INSTANCE_MEMORY controls the amount of memory reserved for
the instance. All the databases defined in the instance get their memory from this area.
The database configuration parameter DATABASE_MEMORY specifies the minimum amount of

shared memory that is reserved for a database. It does not include the database manager shared
memory or the application group memory.
The database configuration parameter MAXAPPLS defines the maximum number of concurrent
applications that can be connected to the database. When this value has been reached, an error is
returned to any new application that tries to connect indicating that the maximum number has been
exceeded.
Database Objects
Table
A collection of data logically arranged in columns and rows
View
A representation of the data in tables
Index
An ordered set of keys each pointing to a row in a table
Schema
All DB2 objects have a two part name and the schema is the first half of that name
e.g.: BOB.STAFF
A schema is an identifier that helps group database objects together.
Schemas can be either implicit or explicit when accessing an object.
Database Application Objects
Sequences
Triggers
User-Defined Functions (UDFs)
Stored Procedures
22
DB2 allows you to create a variety of objects in a database. The objects created in one database are
totally independent from those in another.
As an experienced database user, you should already be familiar with tables, views, indexes, triggers,
user-defined functions, and stored procedures. If you do not come from an Oracle background, a
Sequence Object is used to generate unique, sequential numbers. They are typically used to
generate primary key values. (Sequence objects are not tied to a specific table, unlike IDENTITY
columns. DB2 supports both sequence objects and IDENTITY columns).
In DB2, the term “schema” applies to a somewhat different concept than other database products. In
some databases, a schema is associated with a database user. However, DB2 does not have the
concept of database users. All users are defined in an external security facility which is usually the
operating system. A schema in DB2 is simply the first part of a two-part name for an object. When
you connect to a database, by default, the user ID will be used as the schema and prefixed to all
referenced objects.
For example, suppose that a user called BOB connects to a database and creates a table named T1.
If BOB did not specify a schema with the table name, DB2 will create the table as BOB.T1. Similarly, if
BOB tries to SELECT from the STAFF table using a SQL statement like “SELECT * FROM STAFF”,
DB2 is actually going to re-write the statement as “SELECT * FROM BOB.STAFF”, since all objects
must be qualified with a schema.
BOB can also explicitly create or reference an object in a different schema. For example, BOB might
issue the SQL statement “SELECT * FROM JIM.STAFF”. Since BOB explicitly specified a schema in
this case, DB2 does not use the default schema. This example also highlights the fact that two tables
named STAFF can co-exist – as long as they both reside in different schemas.
What is the point of this? You should be aware that regardless whether you specify a schema or not,
DB2 always creates and references database objects using a schema name. If you do not provide
one, a default one is automatically used. There is more to schemas than the simple introduction we
provided here. You have the ability to control whether a user can create, alter, or drop objects in a
schema, as well as whether a user can create a brand new schema name on-the-fly. We defer a
discussion of these topics until later in the Workshop.
DB2 Architecture and Process Model
ftp://ftp.software.ibm.com/ps/products/db2/info/vr9/pdf/letter/en_US/db2d3e90.pdf Chapter 8 DB2 Process Model
23
Common Processes
db2agent
Coordinator agent that performs database operations on behalf of applications (at least 1
per connection, depending if Connection Concentrator is enabled).
db2sysc
database instance process (one per INSTANCE)
db2tcpcm
tcpip communication/listener
db2agntp
Active sub-agent, spawned if INTRA_PARALLEL (DBM CFG parameter) is set to YES,
and performs database operations for the application. The db2agent process will
coordinate the work between the different db2agntp subagents.
db2pfchr
DB2 asynchronous I/O data prefetcher (NUM_IO_SERVER) – BP prefetchers
db2pclnr
DB2 asynchronous I/O data writer (NUM_IOCLEANER) – BP page cleaners
more info: http://www.ibm.com/developerworks/db2/library/techarticle/0304chong/0304chong.html
24
The “db2sysc” process is the system controller. This is the central process that manages and
coordinates all instance activities.
The “db2tcpcm” process is a “listener” for TCPIP connection requests.
The “db2agent” process acts as a coordinator between DB2 and the application. All application
requests are sent to the “db2agent” process, which in turn will delegate the work to other DB2
processes.
The “db2agntp” process is a sub-agent that is only spawned if intra-partition parallelism is enabled.
Several of these sub-agents can work on a task in parallel, then return their results to the “db2agent”
which initiated the request. When intra parallelism is disabled, there is only one db2agent servicing the
application so there is no need for coordinating agent.
The “db2pfchr” is a “pre-fetcher” for retrieving data from disk before it is actually needed. DB2 can
detect when data might be needed, prior to the actual instruction to fetch, and will asynchronously
spawn 1 or more of these processes to fetch the data.
The “db2pclnr” is a “page cleaner”, responsible for writing dirty pages in memory back to disk. This
process also acts asynchronously so that DB2 does not have to wait for a page to be written out to disk
if it needs room to bring in a new one.
Again, for more information about these processes and others, consult the URL at the bottom of the
slide.
Inter-partition Parallelism (ESE with DPF)
SELECT... A query is divided into parts,

FROM... each being executed in
parallel across multiple
servers.
Data Data Data Data
Database Database Database Database

Partition Partition Partition Partition
25
DB2 also supports inter-partition parallelism. This applies to a partitioned, sometimes called clustered,
DB2 environment. Large databases can be partitioned across multiple physical and/or logical servers
for increased parallelism. Using DB2 Enterprise Server Edition with the Database Partitioning Feature
a database to be partitioned across as many as a 1000 nodes.
Inter-partition parallelism and the partitioning of a DB2 database is completely transparent to

applications.
For example, consider an SQL statement such as “SELECT SUM (col1) FROM T1”
With this type of query, each partition can perform a summation of the column, independent of the
other partitions, and only for it’s part of the data. Once each partition completes its task, DB2 performs
one final summation and returns the value to the application.
Intra-partition Parallelism
SELECT... A query is divided into parts,
each being executed in
FROM... parallel.
Data
Database Partition
26
DB2 supports intra-partition parallelism. This means that within a database, DB2 is able to break up
complex queries into smaller instructions and satisfy the request with parallel processing. In
otherwords, a single server side process has the ability to spawn multiple sub-processes to resolve a
query. These sub-processes can take advantage of multiple CPUs on the server machine, thus further
increasing the performance gains of parallelism.
Inter AND Intra-partition parallelism !!!

SELECT...
A query CAN BE divided into AND divided into parts, each
parts being executed in FROM... being executed in parallel
parallel across multiple
servers.
Data Data Data Data
27
And finally… DB2's architecture can take advantage of both “inter” and “intra” partition parallelism at
the same time. In other words, for a given query, DB2 can break it up across each node in a
partitioned database environment, then, within each partition, divide up the work amongst multiple sub-
agents to resolve the query with even greater parallelism.
Types of Memory used by DBM
Database Manager
Shared Memory
Database Database
Global Memory Global Memory
[1] [numdb]
Application Application
Global Memory Global Memory
[1] [maxappls]
Agent Agent
Private Memory Private Memory
[1] [maxagents]
28
This diagram depicts the high level memory architecture used by DB2. At the top, there is database
manager, or instance, shared memory. This memory is allocated when the instance is started. All
other memory is allocated from, or “attaches” to, this area.
Database global memory and application global memory are allocated when a database is activated.
A database is activated when an application connects to it, or the ACTIVATE DATABASE command is
issued.
Database Global Memory is shared by all applications that use the database and can be quite large
because it includes a database's primary data cache, known as buffer pools.
Application Global Memory is only allocated in partitioned database environments, where the instance
configuration parameter called INTRA_PARALLEL is set to “YES”, or when the Connection
Concentrator is enabled. It is used to allow agent processes to share their "work". Allocation of agent
private memory is performed whenever a DB2 agent process is spawed.
Agent private memory does not get allocated at database activation. Agent private memory is a list of
addresses that can be used for private memory allocations when needed.
On the next slide, we'll drill-down a little bit deeper into each of these memory areas.
DB2 Memory Model

Monitor heap Database Manager Shared Memory Audit buffer size
(mon_heap_sz) (including FCM) (audit_buf_sz)
Utility heap Database Global Memory

(util_heap_sz)
Database heap
Bufferpools (dbheap)
Backup buffer
(buffpage)
(backbufsz)
Log buffer
Restore buffer Extended memory cache (logbufsz)
(restbufsz)
Locklist Catalog cache
(locklist) (catalogcache_sz)
Package cache
(pckcachesz)
Application Global Memory

(app_ctl_heap_sz)
Agent Private Memory Sort heap

Application
Agent stack Statistics heap (sortheap)
heap
(agent_stack_sz) (stat_heap_sz)
(applheapsz)
Statement heap
(stmtheap)
Query heap DRDA heap UDF memory
(query_heap_sz) (drda_heap_sz) Java heap (udf_mem_sz) Client I/O block(remote)
(java_heap_sz) (rqrioblk)
Agent/Application Shared Memory
Application support layer heap

(aslheapsz)
Client I/O block (local)

(rqrioblk)
29
This diagram illustrates each memory area in detail. Without dwelling too much on each area of
memory, here is an example of how to interpret each box.
The box labeled "Catalog Cache (CATALOGCACHE_SZ)" is an area of memory allocated from
"Database heap (DBHEAP)“, which in turn is allocated from Database Global Memory.
If you wanted to make the Catalog Cache very large, you might have to first increase the Database
Heap. From the diagram, you can see that the parameters to modify in this case are “DBHEAP” and
“CATALOGCACHE_SZ”.
Every memory area shown here it’s corresponding parameter name shown in parentheses.
Parameters are located in either the Database Manager or Database configuration files.
For detailed information about the Database Manager or Database configuration parameters, refer to
Chapter 13 of the DB2 Administration Guide: Performance.
Additional Resources
DB2 developerWorks:
Everything You Wanted to Know About DB2 Universal Database Processes
http://www.ibm.com/developerworks/db2/library/techarticle/0304chong/0304chong.html
DB2 Administration Guide: Performance (Highly recommended)

Chapter 13 - "Configuring DB2“
Appendix A - DB2 Registry and Environment Variables
• DB2 v9 Documentation
Chapter 8 – “DB2 Process Model“
ftp://ftp.software.ibm.com/ps/products/db2/info/vr9/pdf/letter/en_US/db2d3e90.pdf
All DB2 Product documentation is available from:

http://www-306.ibm.com/software/data/db2/udb/support/manualsv9.html
• More info:
http://www.ibm.com/developerworks/db2/library/techarticle/0304chong/0304chong.html
30
This slide lists the additional resources mentioned earlier. We recommend consulting them if you want
to learn about these topics in more detail.

DB2 v9 Basic Architecture PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DB2 v9 Basic Architecture PDF

Uploaded by

Copyright:

Available Formats

®

DB2 Technical Workshop

Business Partner Technical Enablement

© 2006 IBM Corporation

DB2 GUI Tools

Control Center Configuration Assistant

Performance Tools Developer Workbench

DB2 Command Line Processor (CLP)

CLP can be run in three different modes:

DB2 Command Line Processor (CLP)... continued

To end interactive or command line mode and terminate the DB2

To end the interactive mode, enter

To execute OS commands, enter !<OS command>

CLP Command Line Options

LIST COMMAND OPTIONS

CLP Command Line Options… continued

Let’s look at some typical examples of changing CLP options.

DB2 Command Editor

Command results are displayed. SQL

The Command Editor appears as a three-tab window:

The DB2 Server Picture

Admin Server My Server

Database 1 Database 2 Database 1

One physical machine has: Each instance (database manager):

The outer blue rectangle depicts the physical hardware of a server.

DB2 Administration Server Process (DAS)

Stopping and starting

A background process to support instance administration

DB2 Admin Server (Windows)

DB2 Profile Registry

DB2 Profile Registry (db2set)

A place to specify environment or platform specific settings

Settings can be applied to various levels

Database Manager Configuration File (DBM CFG)

DB2 Registry DB CFG

Instance - Stopping and Starting

Many parameters are dynamic (take effect immediately).

Changes to other parameters may require an instance

A collection of tables and related objects

Each database includes

Databases are isolated from each other (object independent)

Database Configuration File (DB CFG)

DB2 Registry DB CFG

DB CFG from Command Line

DB CFG from Control Center

AUTOMATIC DBM and DB Configuration Parameters

Some DBM and DB configuration parameters support the value

DBM configuration parameter that supports AUTOMATIC:

DB configuration parameter that supports AUTOMATIC:

The database configuration parameter DATABASE_MEMORY specifies the minimum amount of

DB2 Architecture and Process Model

ftp://ftp.software.ibm.com/ps/products/db2/info/vr9/pdf/letter/en_US/db2d3e90.pdf Chapter 8 DB2 Process Model

more info: http://www.ibm.com/developerworks/db2/library/techarticle/0304chong/0304chong.html

The “db2tcpcm” process is a “listener” for TCPIP connection requests.

Inter-partition Parallelism (ESE with DPF)

SELECT... A query is divided into parts,

Data Data Data Data

Database Database Database Database

Inter-partition parallelism and the partitioning of a DB2 database is completely transparent to

Inter AND Intra-partition parallelism !!!

Data Data Data Data

Types of Memory used by DBM

DB2 Memory Model