Information Management

DB2 Technical Workshop DB2 Basic Architecture

Business Partner Technical Enablement Information Management 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.

Information Management

DB2 GUI Tools

Control Center
Central point of administration

Configuration Assistant
Tool to configure the client A light-weight version of the Control Center

Command Editor
GUI wrapper for command line processor (CLP)

Replication Center
A GUI tool to set up and administer a replication environment and to run the Capture and Apply programs

Journal
Central point for logging DB2 activities

License Center
Central point of DB2 license management

Wizards
Create database Create database objects (tables, views, etc.) Generate DDL Show SQL / Show Command, etc.

Task Center
Central point for scheduling database jobs

Health Center
Central point for DB2 health monitoring Memory Visualizer

Information Center
Find information about tasks, reference material, troubleshooting, sample programs, and related Web sites.

Performance Tools
Storage Management Self-Tuning Memory Manager Visual Explain Event Monitors Memory Visualizer Event Analyser Indoublt transaction Manager

Developer Workbench
New development environment for building stored procedures, user-definde functions, and structured data types. Also useful for creating XQuery statements, registering XML schemas, annotating XML Schema documents for shredding, SQLJ development, etc.

Data Warehouse Manager

Includes reporting, online analytical processing, and data mining applications.

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.

Information Management

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, CLPs 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. 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.

2.

Information Management

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 Processors 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 (!).

Information Management

CLP Command Line Options

LIST COMMAND OPTIONS
No. of retries to connect to backend Request queue wait time (seconds) Input queue wait time (seconds) Command options Option ------a -c -e -f -l -n -o -p -r -s -t -v -w -x -z (DB2BQTRY) (DB2RQTIME) (DB2IQTIME) (DB2OPTIONS) = 60 = 5 = 5 =

Description ---------------------------------------Display SQLCA Auto-Commit Display SQLCODE/SQLSTATE Read from input file Log commands in history file Remove new line character Display output Display interactive input prompt Save output to report file Stop execution on command error Set statement termination character Echo current command Display FETCH/SELECT warning messages Suppress printing of column headings Save all output to output file

Current Setting --------------OFF ON OFF OFF OFF OFF ON ON OFF OFF OFF OFF ON OFF OFF

The DB2 Command Line Processor has several options that can be changed, such as whether autocommit 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 values current status. On the next slide, we see these values can be changed.

Information Management

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/

Lets 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 its 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.

Information Management

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.
7

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 its 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.

Information Management

The DB2 Server Picture

Admin Server (DAS)

My Server
instance 1 instance 2

Database 1

Database 2

Database 1

One physical machine has:

One Administration Server One or multiple instances

Each instance (database manager):

Is a logical server context Can have one or more databases

To help us understand the DB2 Server lets 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 its 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 its 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.

Information Management

DB2 Administration Server Process (DAS)

db2admin {stop | start}
Stopping and starting 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.

Information Management

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.

Information Management

DB2 Profile Registry

Host machine
Database Manager configuration

Instance
Database

DBM CFG

Database Configuration

DB2 Registry
new features, platform specific optimizations special optimizations

DB CFG

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. DB2s 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.

Information Management

DB2 Profile Registry (db2set)

list variables set for instance list all available variables for platform

db2set db2set -all db2set -lr db2set <r>=<value>

list all currently set variables set a registry 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.

Information Management

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 instances configuration and share the instances 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 dont 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.

Information Management

Database Manager Configuration File (DBM CFG)

Host machine
Database Manager configuration

Instance
Database

DBM CFG

Database Configuration

DB2 Registry
new features, platform specific optimizations special optimizations

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.

Information Management

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

or

db2stop [force] 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.

Information Management

DBM CFG
show parameters

get dbm cfg [show detail] update dbm cfg using <p> <v>

update 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 restarting 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.

Information Management

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.

Information Management

Database Configuration File (DB CFG)

Host machine
Database Manager configuration

Instance
Database

DBM CFG

Database Configuration

DB2 Registry
new features, platform specific optimizations special optimizations

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.

Information Management

DB CFG from Command Line

show parameters update parameters

get db cfg for <dbname> [show detail] update db cfg for <dbname> using <p> <v>

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.

Information Management

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 its 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 its workload. Configuration Advisor will then use your answers to compute parameter values and provide recommendations on their setting.

Information Management

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.

Information Management

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.

Information Management

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

Information Management

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.

Information Management

Inter-partition Parallelism (ESE with DPF)

SELECT... FROM...
A query is divided into parts, each being executed in parallel across multiple servers.

Data
Database Partition

Data
Database Partition

Data
Database Partition

Data
Database 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 its part of the data. Once each partition completes its task, DB2 performs one final summation and returns the value to the application.

Information Management

Intra-partition Parallelism
SELECT... FROM...
A query is divided into parts, each being executed in 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.

Information Management

Inter AND Intra-partition parallelism !!!

A query CAN BE divided into parts being executed in parallel across multiple servers.

SELECT... FROM...

AND divided into parts, each being executed in parallel

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 subagents to resolve the query with even greater parallelism.

Information Management

Types of Memory used by DBM

Database Manager Shared Memory

Database Global Memory [1]

Database Global Memory [numdb]

Application Global Memory [1]

Application Global Memory [maxappls]

Agent Private Memory [1]

Agent Private Memory [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.

Information Management

DB2 Memory Model

Monitor heap (mon_heap_sz) Database Manager Shared Memory (including FCM) Audit buffer size (audit_buf_sz) Utility heap (util_heap_sz) Backup buffer (backbufsz) Restore buffer (restbufsz)

Database Global Memory Bufferpools (buffpage) Extended memory cache Locklist (locklist) Database heap (dbheap) Log buffer (logbufsz) Catalog cache (catalogcache_sz)

Package cache (pckcachesz)

Application Global Memory (app_ctl_heap_sz)

Agent Private Memory Application heap (applheapsz) Agent stack (agent_stack_sz) Statistics heap (stat_heap_sz)

Sort heap (sortheap) Statement heap (stmtheap)

Query heap (query_heap_sz)

DRDA heap (drda_heap_sz)

Java heap (java_heap_sz)

UDF memory (udf_mem_sz)

Client I/O block(remote) (rqrioblk)

Agent/Application Shared Memory Application support layer heap (aslheapsz) Client I/O block (rqrioblk) (local)

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 its 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.

Information Management

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: More info:

http://www-306.ibm.com/software/data/db2/udb/support/manualsv9.html 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.