DB2-V10 PerfClinic Workbook v20120706

IBM Software
Information Management
DB2® 10 for LUW Performance Tuning and

Monitoring Clinic
Hands-On Labs Workbook
V2012-07-06
Table of Contents
DB2 PERFORMANCE MONITORING & TUNING INTRO ............................. 3
DB2 ESSENTIAL PERFORMANCE & MONITORING ................................... 26
DB2 SQL QUERY TUNING ............................................................................ 128
DB2 PERFORMANCE CLINIC – LOCKING................................................... 190
DB2 PERFORMANCE CLINIC – LOGGING .................................................. 209
DB2 MAINTENANCE UTILITIES & PERFORMANCE................................... 222
DB2 Performance Tuning and Monitoring Clinic Workbook page 2 of 251.

IBM Software
DB2® Performance Tuning & Monitoring Intro

Hands-On Lab

IBM Software
Table of Contents
1 Introduction ..........................................................................................................................................................................................3
2 About this Lab......................................................................................................................................................................................3
3 Suggested Reading .............................................................................................................................................................................3
4 Environment Requirements and Setup .............................................................................................................................................3
4.1 Unpacking the image ..........................................................................................................................................................................................3
4.2 Preparation Step .................................................................................................................................................................................................4
4.3 Start the Virtual Machine .....................................................................................................................................................................................4
4.4 Login to the Virtual Machine and Accept the License Agreement.......................................................................................................................6
4.5 Open the Terminal Window.................................................................................................................................................................................9
5 Database Creation Best Practices and Exercises ..........................................................................................................................10

5.1 Create customized database ............................................................................................................................................................................11
5.2 Registry Variables .............................................................................................................................................................................................13
5.2.1 DB2_MEM_TUNING_RANGE ..........................................................................................................................................................13
5.2.2 DB2MEMDISCLAIM..........................................................................................................................................................................13
5.2.3 DB2_SMS_TRUNC_TMPTABLE_THRESH.....................................................................................................................................14
5.3 Buffer pools and Tablespaces...........................................................................................................................................................................14
5.3.1 Create customized Buffer pools and Tablespaces ...........................................................................................................................15
5.3.2 Create dedicated tablespace for LOB/LONG data............................................................................................................................16
5.4 Configuration Advisor........................................................................................................................................................................................16
6 Collecting Baseline Information .......................................................................................................................................................19

6.1 System Level.....................................................................................................................................................................................................19
6.2 Database Level .................................................................................................................................................................................................20
7 Summary.............................................................................................................................................................................................22
8 Cleanup...............................................................................................................................................................................................22
DB2 Performance Clinic Lab

© Copyright IBM Corp. 2012. All rights reserved Page 2 of 23

IBM Software
1 Introduction
DB2 10 is an enterprise database engine with a rich set of features and tools providing unmatched capabilities to achieve best
performance. It contains innovative features for delivering information on demand and scaling databases to new levels.
2 About this Lab

In this first introductory lab we take you through setting up a new database for optimal performance. Specifically, you will learn
• How to setup tablespaces and buffer pools
• How to use the Configuration Advisor to establish an initial well-performing database and instance configuration
• How to collect information that identifies system resources
• How to collect information about the database environment
In this part of the lab, the attendee will work with simply preparing the DB2 environment for proceeding through the labs.
3 Suggested Reading
Best practices for DB2 for Linux, UNIX, and Windows
Practical guidance for the most common DB2 10 product configurations and use this knowledge to improve the value of your
DB2 data servers.
http://www.ibm.com/developerworks/data/bestpractices/
4 Environment Requirements and Setup

To complete this lab you will need the following:
• DB2 Performance Clinic VMware® image
• VMware Player 2.x or VMware Workstation 6.5 or later
4.1 Unpacking the image

The image is delivered in a self-extractable set of zip files. For easy handling the files are compressed to 700MB volumes.
Download all the volumes to the same directory.
Double click the executable file and select the destination folder.


IBM Software
4.2 Preparation Step

1. Choose the DB2_Enterprise_10….vmx file when first opening the lab image in the /DB2v10Performance... folder and
run it.
Figure 1 – Opening a VMware Image File
4.3 Start the Virtual Machine
Start the VMware image by clicking the button in VMware Workstation if it is not already on.


IBM Software
Note: Please wait for the first boot setup process to complete.
The system will power up like any other Linux system and will come to the state as shown in the next picture below.
Figure 2 – Start the Virtual Machine
After the virtual machine has finished booting up, you can now work inside the virtual machine environment. To bring focus into
the virtual machine environment, click inside the virtual machine screen with your mouse or click on the “Full Screen” button
in the toolbar on top of the VMware window.
After clicking on the screen, you may not see your mouse pointer anymore, this is normal as you are now operating in a
command line mode inside the virtual machine.
You can bring focus to the host operating system at any point by pressing “Alt + Ctrl” at the same time.


IBM Software
4.4 Login to the Virtual Machine and Accept the License Agreement
You will see a pop-up message asking you to read and accept the License Agreement.
Figure 3 – Linux Distribution Statement
Use the “Page Down” key to scroll down and read the full license agreement. Once you have read the agreement,
select “Yes, I Agree to the License Agreement” and click “Next” to go to the next screen.
This will take you to the VMware Tools License Agreement.
Figure 4 – SUSE Linux Enterprise Server License Agreement


IBM Software
Figure 5 – VMware Tools License Agreement
select “Yes, I Agree to the License Agreement” to go to the next screen. This will take you the IBM DB2 10
License Agreement:
Figure 6 – DB2 V10 License Agreement


IBM Software
select “Yes, I Agree to the License Agreement” to go to the next screen. This will take you the IBM
Installation Manager License Agreement:
Figure 7 – DB2 V10 Trial Version Notice
This screen shows all of the Software Licenses, and Non-IBM license agreements that were displayed in all of the
previous screens. In order to use this image, you must accept all of the listed agreements that were displayed in the
previous screens. Select “Next” to finish. If you do not agree with the license agreements, select “Abort” and the
virtual machine will be shutdown automatically.
Figure 8 – License Agreements


IBM Software
At the login prompt, login with the following credentials:

o Username: db2inst1
o Password: password
Figure 9 – Login credentials
4.5 Open the Terminal Window
1. Open a new terminal window by right-clicking on the Desktop and choosing the “Open Terminal” item:
Figure 10 – Opening a Terminal
2. Start the Database Manager as follows:
Enter the command “db2start” to start the database instance. Make sure the instance is started successfully.
(Note: If you notice a message that says “The database manager is already active”, that’s OK.
Please continue to the next section).


IBM Software
In order to enable the aliases defined for this lab and all labs that follow, copy the /home/db2inst1/labbashrc to
/home/db2inst1/.bashrc and source that file.
cp /home/db2inst1/labbashrc .bashrc
. .bashrc
Attention: You need to type a space between the two dots.
5 Database Creation Best Practices and Exercises

It is important to be aware of the default behavior when using the simplest form of the CREATE DATABASE command, as many
of the default settings has performance implications. For instance, the command “CREATE DATABASE <dbname>” results in:
• Configuration Advisor running against the database with somewhat conservative options
o Best Practice: Run the Configuration Advisor, after database has been created and input information, such as
the concurrent number of users and types of transactions. Doing this assumes that DB2 tuning experience is at
a beginner level.
• Automatic statistics collection being enabled
o Best Practice: To ensure that the optimizer has a good set of working statistics leave this setting as is. Certain
tables may require special designations, like “Volatile.” Additionally, a statistics profile can be registered for
tables requiring more than the default collection method. This profile will be respected by the automatic
statistics gathering process. See the DB2 Information Center for more information and restrictions on this
feature.
• Adaptive Self Tuning Memory being enabled
o Best Practice: Leave this feature on when the system is a dedicated DB2 server. However, with respect to the
nature and criticality of memory allocation, it is best employed after thorough system testing. Monitor system
memory and the db2diag.log for actual heap allocations. For a DPF environment, see DB2 Information Center
for further considerations including selecting a “tuning node”.
• Unicode database
o This designation is required if you intend to use the XML native data type or if multi byte code set is required.
If required, be mindful to the collating sequence you choose, Unicode culturally correct collating sequences like
UCA500R1_xxx can cause additional CPU overhead. There are alternative collations like SYSTEM_819_BE
that take advantage of Unicode databases that contain data in only one language. They use the same lookup
table-based collation algorithm as single-byte collations such as SYSTEM_819, making them very efficient.
• Automatic Storage using a single location for containers (defined by the database manager configuration parameter
DFTDBPATH)


IBM Software
o Though additional storage paths can be added to a database with the ALTER DATABASE command, it is
advisable to establish multiple storage paths on dedicated devices before the database is populated. When
you create tablespaces, by default they will be designated to use automatic storage, be mindful to specify
attributes like INITIALSIZE, MAXSIZE, and INCREASESIZE.
• Database control and log files being stored in same location as tablespace containers (also defined by the database
manager configuration parameter DFTDBPATH)
o For optimal performance move the transaction log files to their own dedicated file system after database
creation.
• Default page size of 4K for default buffer pool and the SYSCATSPACE, TEMPSPACE1, and USERSPACE1
tablespaces
• Isolation level being set to Cursor Stability with currently committed semantics
• Detailed deadlocks event monitor (DB2DETAILDEADLOCK) created and enabled (This monitor is deprecated, but used
for transitional purposes
Some of the best practices cited above cannot actually be addressed until after the database has been created, while other
factors can be addressed with the CREATE DATABASE command itself. The autonomic and automatic default options should
be kept.
You will definitely want to address the placement of log files and tablespace containers. By default, db2 database metadata,
transaction log files and tablespace containers are all placed in the same default location. While this works, in a real production
system this can result in severe performance degradation, especially for large, transaction laden databases.
5.1 Create customized database

1. Create a database with non default locations for transactional log files and tablespaces. Issue the following command
from the terminal window as db2inst1:
db2 "create database INTRO ON /data1, /data2 DBPATH ON /home/db2inst1

RESTRICTIVE"
This command uses the ON clause which indicates that the database will use automatic storage and all automatic tablespace
containers will be created under specified locations. The “DBPATH ON” clause indicates that database metadata along with log
control and data files will be created under: /home/db2inst1. If DBPATH is not specified these things will be created on the first
path found in the ON clause.
2. The home directory is acceptable for database metadata but leaving the log data and control files in the same location
is not the best for transactional performance. Issue the following command to verify location of log files:
db2 get db cfg for intro |grep -i "path to log"


IBM Software
Expected output:
Changed path to log files (NEWLOGPATH) =

Path to log files = /home/db2inst1/db2inst1/NODE0000/SQL00001/LOGSTREAM0000/
You can see that the log file location is the same as the one for database metadata.
DB2 Object Location
Database configuration file home/db2inst1/db2inst1/NODE0000/SQL00001

SQLDBCON
home/db2inst1/db2inst1/NODE0000/SQL00001
Database directory
Contains files needed for:
• buffer pool information

• history information
• log control files
• storage path information
• tablespace information
Directory for event monitor data home/db2inst1/db2inst1/NODE0000/SQL00001/MEMBER0000/db2event
Directory for transaction log files home/db2inst1/db2inst1/NODE0000/SQL00001/LOGSTREAM0000
Local database directory for the home/db2inst1/db2inst1/NODE0000/sqldbdir
instance
3. Change the path to a completely separate location. Issue this command from terminal:
db2 "update db cfg for intro using NEWLOGPATH /logs"

4. Verify the path has been changed. Issue this command:
db2 get db cfg for intro |grep -i "path to log"
Expected output:
Changed path to log files (NEWLOGPATH) = /logs/NODE0000/LOGSTREAM0000

Path to log files = /home/db2inst1/db2inst1/NODE0000/SQL00001/LOGSTREAM0000/
Attention: Note that “Path to log files” still shows the old location but the effective log path is the location indicated by
NEWLOGPATH parameter.


IBM Software
We had also specified the RESTRICTIVE key word in the create database command. (This can be checked by displaying the
database configuration file with the “get db cfg” command under Restrict Access). Without it, db2 catalog information is readable
by PUBLIC, i.e. anyone connected to the database. This will revoke the authorization to PUBLIC and make the database more
secure. See DB2 Information center for other restrictions.
5.2 Registry Variables

There are three types of configurations in a DB2 environment:
• Database manager configuration
• Database configuration
• Registry variables
So far, we have looked at database and database manager configurations. In this section we look at some significant
performance related registry variables. Note that the Configuration Advisor does not enable any registry variables. Remember
that for registry variables to take effect a complete db2 recycle using db2stop and db2start is required.
5.2.1 DB2_MEM_TUNING_RANGE
This registry variable is related to self tuning memory manager (STMM). If STMM is being used, it will take more memory, as
needed, on the server as long as there is free memory available. This may cause problems on systems where you need to
leave some memory for another application or for the system. The syntax is as follows:
db2set DB2_MEM_TUNING_RANGE=MINFREE, MAXFREE
MINFREE and MAXFREE are percentage numbers. So if you want to dedicate no more than 60% of system memory to db2,
you would set MINFREE to 40% which means STMM should take no more than 60% of system memory so there is always at
least 40% free memory available. STMM will release memory when it is not needed but you may want to control how much
memory STMM gives up. For example, if the requirement is that STMM should retain al least 20% of system memory, then
MAXFREE would be set to 80%.
1. In order to make these settings, execute the following from command terminal:
db2set DB2_MEM_TUNING_RANGE=40,80
5.2.2 DB2MEMDISCLAIM
DB2 agents may have some associated paging space. This paging space may remain allocated even after the associated
memory has been freed depending on the platform and virtual memory tunings. DB2MEMDISCLAIM, when set, indicates that
explicit requests should be made by DB2 to free associated paging space as well. This leads to smaller paging space
requirements and possibly less disk activity from paging. On systems where memory is tight and paging space is being used,
this may provide a performance improvement.
1. Enable it as follows from command terminal
db2set DB2MEMDISCLAIM=YES
db2stop force


IBM Software
db2start
5.2.3 DB2_SMS_TRUNC_TMPTABLE_THRESH
By default, when a temporary table is not needed it is truncated to zero pages. If there is a lot of temp table activity, this can
degrade performance. Using this registry variable, one can specify the number of extents that should be preserved upon
truncation so that when the table is reused there are pre allocated extents available for use.
1. Run the following command to indicate that 10 extents should be preserved when truncating any temp table:
db2set DB2_SMS_TRUNC_TMPTABLE_THRESH=10
Restart DB2 so that all changes take effect.
db2stop force
db2start
5.3 Buffer pools and Tablespaces

1. When a database is created, a default user tablespace and bufferpool are created. Issue this command to check which
tablespace has been created:
db2 connect to INTRO

db2 list tablespaces show detail
There should be three tablespaces created:
• SYSCATSPACE (catalog data)
• TEMPSPACE1 (system temp)
• USERSPACE1 (user data)
USERSPACE1 is the default tablespace created and it has a page size of 4k. DB2 supports four page sizes: 4k, 8k, 16k and
32k. You may have tables with large rows that do not fit on a 4k page, so tablespaces with larger page sizes should also be
created. However, larger page size tablespaces need buffer pools with matching page size.
2. Check to see what kind of buffer pools have been created by using the following query:
db2 "select substr(BPNAME, 1,25) as BPNAME, NPAGES, PAGESIZE FROM

SYSCAT.BUFFERPOOLS"
Expected output looks like:
BPNAME NPAGES PAGESIZE

------------------------- ----------- -----------
IBMDEFAULTBP -2 4096
There is only one bufferpool for all type of tables and activities in the entire database. Also note that it is enabled for Automatic
memory tuning. NPAGES value of -2 indicates that IBMDEFAULTBP buffer pool has been enabled for automatic tuning.


IBM Software
5.3.1 Create customized Buffer pools and Tablespaces

Create automatic buffer pools for the rest of the page sizes. Create a dedicated buffer pool for the system temp tablespace. It is
always a good design to segregate temp activity to its own buffer pool. Temp space activity, when heavy, can be disruptive to
regular database activity due to frequent creation and removal of temp tables.
1. Run the following statements to achieve the above stated goals:
db2 create bufferpool bp8k size automatic pagesize 8k

db2 create bufferpool tempbp size automatic pagesize 4k
2. Run the following command to verify the results:
db2 "select substr(BPNAME, 1,25) as BPNAME, NPAGES, PAGESIZE FROM

SYSCAT.BUFFERPOOLS"
Expected output:
BPNAME NPAGES PAGESIZE

------------------------- ----------- -----------
IBMDEFAULTBP -2 4096
BP8K -2 8192
BP16K -2 16384
BP32K -2 32768
TEMPBP -2 4096
3. Now that buffer pools have been created, we can create the corresponding tablespaces. Execute the following from
command terminal:
db2 create tablespace tbsp8k pagesize 8k bufferpool bp8k

4. Verify that all tablespaces are associated with the intended buffer pools. Run the following query:
db2 "select substr(bpname,1,25) as BPNAME, substr(tbspace,1,25) as TBSPACE

from syscat.bufferpools B ,syscat.tablespaces T
where B.BUFFERPOOLID=T.BUFFERPOOLID"
Expected output:


IBM Software
BPNAME TBSPACE
------------------------- -------------------------
IBMDEFAULTBP SYSCATSPACE
IBMDEFAULTBP TEMPSPACE1
IBMDEFAULTBP USERSPACE1
IBMDEFAULTBP SYSTOOLSPACE
BP8K TBSP8K
BP16K TBSP16K
BP32K TBSP32K
All looks fine except that TEMPSPACE1 is still associated with IBMDEFAULTBP. Recall that we had created a dedicated
bufferpool for TEMPSPACE1 but we never altered the tablespace to point to it. So TEMPBP buffer pool exists but is not being
used by TEMPSPACE1.
5. Run the following statement to fix it:
db2 alter tablespace TEMPSPACE1 bufferpool TEMPBP

6. Run previous query (step #4) again to verify TEMPSPACE1 is pointing to BPTEMP.
5.3.2 Create dedicated tablespace for LOB/LONG data

If the database is going to contain significant amount of LOB/LONG data, it is a good idea to create dedicated tablespace(s) for
LOB data. There are two design reasons for it. First, LOB data can be quite large so it can quickly max out the capacity of your
regular data tablespaces. Secondly, LOB data is not buffered in DB2 bufferpools, therefore you want to ensure that it is being
buffered in the file system cache. Since regular data is buffered in buffer pools there is no need for double buffering it in file
system cache. However, for LOB data file system caching is critical.
1. Execute the following command to create dedicated tablespace for LOB data:
db2 create LARGE tablespace tbsplong managed by automatic storage FILE

SYSTEM CACHING
5.4 Configuration Advisor

1. When a database is created in DB2, the Configuration Advisor is run under the covers automatically using default
values. This behavior can be disabled with the db2set command before creating a database:
db2set DB2_ENABLE_AUTOCONFIG_DEFAULT=NO
Configuration advisor was also run for INTRO database with default values but we want to run it again with user supplied input.
2. You will use the AUTCONFIGURE command to provide database usage characteristics and get recommended values
to improve the initial configuration of the database with respect to the input. Here we are only retrieving
recommendations (apply none) but you can also optionally apply recommendations as well (apply db only,
apply db and dbm).


IBM Software
db2 autoconfigure using mem_percent 50 tpm 200 admin_priority performance

is_populated no num_remote_apps 200 isolation cs apply none
Lab
Keyword Values Default Explanation
Setting
Mem_percent 1 – 100 25 Percentage of instance memory that is assigned to the 50

database.
Workload_type Simple, Mixed Simple workloads tend to be I/O intensive mostly Default
transactions whereas complex ones tend to be CPU
Mixed,
intensive and mostly queries
Complex
Num_stmts 1 – 1000000 10 Number of statements per unit of work Default
Tpm 1 – 2000000 60 Transactions per minute 200
Admin_priority Performance, Both Optimize for better performance or better recovery time. Perf.
Recovery,
Both
Is_populated Yes, no Yes Is the database populated with data No
Num_local_apps 0 – 5000 10 Number of connected local applications Default
Num_remote_apps 0 – 5000 10 Number of connected remote applications 200
Isolation RR, RS, CS. RR Maximum Isolation level applications connecting to this CS
database
UR
Bp _resizable Yes, no Yes Indicates if buffer pools can be re-sized. Default


IBM Software
AUTOCONFIGURE OUTPUT:
Figure 11 – Auto configure output


IBM Software
6 Collecting Baseline Information

When you start to think about how to configure your DB2 database and system environment, you need to be aware of what
system resources are at your disposal. This includes things like processing power, memory, and disk storage. Though DB2 can
detect most resources and configure them accordingly, it is always a good idea to understand them yourself.
In this section, we will look at some of the tools that are typically used to collect this information. We will also explore how to
collect DB2 configuration information. Keeping track of such system and database level information is important in both
understanding how the system changes over time and to help gauge what effects of any tuning has on the system.
6.1 System Level

In this part of the exercise, we are going to use the DB2 Problem Determination tool (db2pd), which is both useful and flexible,
to better understand our system environment. The tool is much more robust and powerful than demonstrated here, and it is very
efficient to use it to collect system-level information.
Additionally, it nicely transcends the different operating systems and can be used anywhere where DB2 is installed. The content
can differ across operating systems, but more or less provides the same information,
For this purpose, issue the following command:
db2pd –osinfo disk /data1
Using this information, please identify the following:
What Operating System and Version is running? _____________________________
What is the Nodename? _________________________________________________
What processors are being used? _________________________________________
How many processors? _________________________________________________
What is the speed of the processors in MHz? ________________________________
How much total memory is on the machine in MBs? ___________________________
How much virtual memory has been set? ____________________________________
How much memory is currently free? _______________________________________
What is total disk storage size? ____________________________________________
How much disk storage is available? _______________________________________


IBM Software
As you can tell, this is all very useful information to know prior to database tuning.
Similar information can also be obtained using SQL if you have already created a database and are connected to it. This is
useful if you want to programmatically collect such information.
1. To see the system information for INTRO database, issue the following commands:

db2 "select substr(name,1,20) as name, substr(value,1,20) as value from
sysibmadm.env_sys_resources"
6.2 Database Level

Once you have created a database, it is usually useful to maintain some kind of historical records of its configuration. This can
help you better understand how the configuration of the database evolves over time, as well as help identify configuration
changes that affect performance.
Such details usually include configuration information about the database manager and database configuration files, buffer
pools, tablespaces, and even the DDL of your database objects.
The db2support problem analysis and environment collection tool is essentially a one-stop-shop for all environment
information. With one command you can collect all of the environment and database information such as database manager
configuration, database configuration, registry variables, tablespace layouts, buffer pool sizes and a lot more. Though it is
primarily intended for DB2 support purposes, it also works nicely to collect information about a system with which you may not
be familiar.
1. Run db2support from the command window terminal:
cd /home/db2inst1/
mkdir envdata
cd ~/envdata
db2support . –d INTRO –c
Attention: For the purpose of this lab, you should take a look at the generated files, which can be found in the
/home/db2inst1/envdata directory, please continue in the next instruction.
2. Once the tool finishes, it will have all the information collected and available in db2support.zip file. Unzip the file to see
the db2support.html file by issuing the following command.
unzip db2support.zip
3. Start up Firefox from My computer menu in the lower left hand corner. Once Firefox browser is up, go to File Open
File, specify location for db2support.html file to bring it up in the browser.
(Note: If you notice a message that says “Server not found”, just ignore it)


IBM Software
You should now be able to see all the environment configuration information in the browser broken up into different sections. A
sample of the output produced is listed below:
Figure 12 – Opening a db2support HTML report
Browse and review the configuration information dumped by db2support. Based on the output produced, answer the following
questions:
Q1: What databases exist, other than INTRO database?
Q2: Can you identify the tablespace containers for all the tablespaces in the INTRO database?
Q3: What is db2 version and fixpack level being used?
So far we have looked at tools to check the configuration information. There are times when you need to dump the database
schema containing DDL for all the tables, indexes, triggers, stored procedures and functions that were created by the user. This


IBM Software
can be done with the db2look command. This command offers a host of options to tailor the results to your needs. With
respect to performance related information the following parameters can be used:
• -l : bufferpools and tablespaces, created
• -f : database parameters that impact the query optimizer
• -x or -xd : authorizations specified with the RESTRICTIVE parameter of the CREATE DATABASE command
• -m ; statistics.
Issue the following command from command terminal:
db2look -d INTRO –f –o queryParameters.out

db2look –d INTRO –l –o BPSandTBS.out
View the output files specified. In the queryParameters.out file, you will see the database manager and database parameters
along with any registry settings that affect performance. In the BPS_TBS.out file, you will see the bufferpools and tablespaces
and their DDL.
7 Summary
You can see by now that there are three key areas that are important to understand when trying to avoid performance
degradations of your system: configuration, monitoring, and performance troubleshooting. One of the best practices around
performance tuning and monitoring is to collect baseline information. We explored some of the tools provided by DB2 to gather
the initial data that will help you to understand system performance under both operational and troubleshooting conditions.
8 Cleanup
At this point, we will must clean up both the database and environment to prepare for the next section. Please issue the
following commands:
db2 force applications all

db2 terminate
db2 drop db intro
db2set DB2_SMS_TRUNC_TMPTABLE_THRESH=
db2set DB2_MEM_TUNING_RANGE=
db2set DB2MEMDISCLAIM=NO
db2stop


IBM Software
© Copyright IBM Corporation 2012

All Rights Reserved.
IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada
IBM, the IBM logo, ibm.com and Tivoli are trademarks or registered
trademarks of International Business Machines Corporation in the
United States, other countries, or both. If these and other
IBM trademarked terms are marked on their first occurrence in this
information with a trademark symbol (® or ™), these symbols indicate
U.S. registered or common law trademarks owned by IBM at the time
this information was published. Such trademarks may also be
registered or common law trademarks in other countries. A current list
of IBM trademarks is available on the Web at “Copyright and
trademark information” at ibm.com/legal/copytrade.shtml
Other company, product and service names may be trademarks or

service marks of others.
References in this publication to IBM products and services do not

imply that IBM intends to make them available in all countries in which
IBM operates.
No part of this document may be reproduced or transmitted in any form

without written permission from IBM Corporation.
Product data has been reviewed for accuracy as of the date of initial
publication. Product data is subject to change without notice. Any
statements regarding IBM’s future direction and intent are subject to
change or withdrawal without notice, and represent goals and
objectives only.
THE INFORMATION PROVIDED IN THIS DOCUMENT IS

DISTRIBUTED “AS IS” WITHOUT ANY WARRANTY, EITHER
EXPRESS OR IMPLIED. IBM EXPRESSLY DISCLAIMS ANY
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE OR NON-INFRINGEMENT.
IBM products are warranted according to the terms and conditions of

the agreements (e.g. IBM Customer Agreement, Statement of Limited
Warranty, International Program License Agreement, etc.) under which
they are provided.


IBM Software
DB2® Essential Performance Monitoring

Hands-On Lab

IBM Software
Table of Contents
1 Introduction..........................................................................................................................................................................................4
3 Lab Preparation ...................................................................................................................................................................................5
3.1 Start Virtual Machine and DB2............................................................................................................................................................................ 5
3.2 Initialize Environment.......................................................................................................................................................................................... 7
4 Configuring Performance Monitoring................................................................................................................................................8

4.1 DB Configurations for Monitoring Framework..................................................................................................................................................... 8
4.2 System Monitor Switches.................................................................................................................................................................................. 10
5 Interfaces for database monitoring .................................................................................................................................................12

5.1 CREATE EVENT MONITOR (change history) statement................................................................................................................................. 12
5.2 Identifying the statements that affect a table .................................................................................................................................................... 15
5.3 Creating event monitors that write to tables...................................................................................................................................................... 17
5.4 Displaying a list of event monitors created in your database............................................................................................................................ 20
5.5 Event Monitor Data Retention from Release to Release .................................................................................................................................. 21
6 Monitoring Current Activity ..............................................................................................................................................................23

6.1 Applications....................................................................................................................................................................................................... 24
6.2 System Perspective .......................................................................................................................................................................................... 29
6.3 Data Object Perspective ................................................................................................................................................................................... 29
6.4 Monitor Elements .............................................................................................................................................................................................. 30
6.5 Activity Perspective........................................................................................................................................................................................... 31
6.6 Statistics............................................................................................................................................................................................................ 31
7 System Bottlenecks ..........................................................................................................................................................................33

7.1 I/O wait.............................................................................................................................................................................................................. 33
8 Monitoring Database I/O ...................................................................................................................................................................39

8.1 Snapshot on Database for I/O indicators .......................................................................................................................................................... 40
8.2 Evaluating Read Efficiencies ............................................................................................................................................................................ 42
8.3 SNAPDB ADMINISTRATIVE VIEW.................................................................................................................................................................. 44
8.4 SNAP_GET_DB TABLE FUNCTION................................................................................................................................................................ 45
9 Monitor and Tune Bufferpools .........................................................................................................................................................46

9.1 Bufferpool Hit Ratios ......................................................................................................................................................................................... 46
10 Tools ...................................................................................................................................................................................................48
10.1 DB2TOP............................................................................................................................................................................................................ 48
11 Optim Performance Manager OPM ..................................................................................................................................................54

11.1 Installation of Optim Performance Manager (OPM) Software .......................................................................................................................... 54
11.2 Create the SAMPLE Database ......................................................................................................................................................................... 54
11.3 Start the OPM Web Console............................................................................................................................................................................. 54
11.3.1 Delete Connections .......................................................................................................................................................................... 56
DB2 Essentials Performance Monitoring


IBM Software
11.4 Manage Database Connections........................................................................................................................................................................ 58

11.4.1 Alerts Configuration and Notification ................................................................................................................................................ 63
11.4.1.1 Configure Health Alerts............................................................................................................................................................... 64
11.4.1.2 Configure Performance Alerts..................................................................................................................................................... 66
11.4.1.3 Alert Notification.......................................................................................................................................................................... 68
11.5 Run Workload ................................................................................................................................................................................................... 71
11.6 Review Health Summary .................................................................................................................................................................................. 72
11.6.1.1.1 Analyze Lock Wait ................................................................................................................................................................... 74
11.6.1.1.2 Analyze Sort Overflows............................................................................................................................................................ 76
11.6.1.1.3 Analyze I/O Alerts .................................................................................................................................................................... 79
11.7 Overview of a selected database...................................................................................................................................................................... 82
11.7.1.1.1 View Historical Data................................................................................................................................................................. 83
11.7.1.1.2 View Real-Time Data ............................................................................................................................................................... 84
11.7.1.2 Connections to a database ......................................................................................................................................................... 84
11.7.1.2.1 View Overall Connection Details.............................................................................................................................................. 85
11.7.1.2.2 View SQL Details in a Connection ........................................................................................................................................... 88
11.7.1.2.3 View Current Application Connections .................................................................................................................................... 90
11.7.1.3 Buffer Pool and I/O ..................................................................................................................................................................... 92
11.7.1.4 Reports ....................................................................................................................................................................................... 96
11.7.1.4.1 SQL Baseline Comparison Reports ......................................................................................................................................... 97
12 Cleanup.............................................................................................................................................................................................101


IBM Software
1 Introduction
DB2’s performance monitoring framework has been improved in DB2 10. Historically DB2’s monitoring utilities and interfaces
have been based on the monitoring elements presented by the Snapshot Monitoring stream. DB2’s Health monitor, snapshot
commands, administrative views and table functions all utilize the Snapshot Monitoring stream of monitoring elements.
DB2 V10 brings along with it a new and full complement of monitoring table functions and administrative views that enable you
to take advantage of the monitoring framework. The monitoring framework is robust, light weight and features many identical or
similar monitoring elements as the Snapshot monitoring.
This lab is intended to teach you the essentials to monitoring a DB2 database system. The scope of a “DB2 database system”
extends capabilities through the Enterprise Edition, and up to and including version 10. This module is intended for someone
who has some experience with DB2 and wishes to broaden their knowledge in the area of performance-related monitoring.
These labs are performed on a VMware image of a 32bit SUSE Linux machine with minimal resources declared. There are
some commands used in the lab that are typically found on Linux/Unix systems, however basic Unix command-line tools can be
downloaded and easily employed on Windows-based machines at no cost. Additionally, comparable commands are available in
the Windows environment, like find in place of grep.
There are two main tips that will make the lab progress better.
1. Use the up arrow key to recall previous commands. These commands can be edited and re-executed as needed.
2. Follow all the instructions, don’t skip steps. These labs have been created so that they can be rerun but to avoid that
please follow all instructions.
2 Suggested Reading
Information Management Technical Library at developerWorks
Contains articles and tutorials and best practices
http://www.ibm.com/developerworks/views/db2/library.jsp
http://www.ibm.com/developerworks/data/bestpractices
An Expert's Guide to DB2 Technology

Great read and useful information.
http://blogs.ittoolbox.com/database/technology
DB2 10 Fundamentals Certification Study Guide

Learn the basics and get ready for certification


IBM Software
3 Lab Preparation
Before getting started with the lab exercises you will set up you’re environment then work through a series of exercises focused
on DB2 performance monitoring techniques.
3.1 Start Virtual Machine and DB2

You may skip this section if you have started your VM and db2 instance in a previous lab or exercise.
1. Choose the DB2_Enterprise_10….vmx file when first opening the lab image in the /DB2v10Performance... folder and
run it.
Figure 1 – Opening a VMware Image File
2. If this is the first time this virtual machine has been started, a series of licensing agreements will prompt you. To
proceed, acknowledge by responding by selecting the “Yes, I Agree to the License Agreement” selection.


IBM Software
Figure 2 – License Agreements
3. Login in at the console prompt as db2inst1. You will be prompted for the password which is password. You may be
prompted for the root password as well, if so, it is also password.
Figure 3 – Login credentials
4. Open a terminal window as follows:

• Open a new terminal window by right-clicking on the Desktop and choosing the “Open Terminal” item:


IBM Software
From the new terminal session start the Database Manager as follows:
• Enter the command “db2start” to start the database instance. Make sure the instance is started successfully. (Note:
If you notice a message that says “The database manager is already active”, that’s “OK. Please continue to the
next step.)
• In order to enable the aliases defined for this lab, copy the /home/db2inst1/labbashrc to /home/db2inst1/.bashrc and
source that file.
cd ~
cp labbashrc .bashrc
. .bashrc
3.2 Initialize Environment

You have been provided with a script, which creates a database, the needed tablespaces and the tables that you will work with
in this portion of the lab. These are mandatory steps and must be completed, as mandatory steps so often are.
1. If you no longer have the terminal opened from previous exercise: By right clicking on the Gnome desktop (as in 3.1)
open a new terminal window.
2. While logged in as user “db2inst1”, change your working directory to the folder containing the script mentioned.
edb2scripts
The command will take you to directory /home/db2inst1/Documents/LabScripts/db2pt/essential/db2scripts.
3. Before executing, take a look at the script, and note how the database is created. It will first try to drop the db2pt
database, in case one exists from previous labs, and then create a new version of the database.
cat createDB.db2
Note: You can use the arrow keys to scroll up and down in the script and type the letter “q” to exit anytime.


IBM Software
4. Execute the script as follows:
db2 -tvf createDB.db2
Note: Make sure that the create database SQL statement has finished successfully. The following message should be
returned after the successful completion of this SQL statement:
DB20000I The CREATE DATABASE command completed successfully.
5. Turn off system monitor switches and restart the instance.
db2 -tvf dftmonOff.db2

db2stop force
db2start
db2 terminate
4 Configuring Performance Monitoring

Before you start performance monitoring, you want to make sure that your system and your session are configured to collect the
information that you need. First you will examine and practice with the database configuration parameters that control the
collection of data for the monitoring table functions. Then you will look at and enable the system monitor switches used to collect
data for Snapshot monitoring.
4.1 DB Configurations for Monitoring Framework

DB2® Version 10 provides new monitor elements that enable you to perform more granular monitoring, without using the
monitor switches or snapshot interfaces. Database-wide monitoring control is provided by database configuration parameters.
With the new monitor elements and infrastructure, you can use SQL statements to efficiently collect monitor data from memory
to determine whether specific aspects of the system are working correctly and to help you diagnose performance problems.
With the new access methods, you can get the data you need without using the snapshot interfaces. The increased monitoring
granularity gives you more control over the data collection process; collect the data you want from the source you want. The
monitoring framework also reduces performance monitoring overhead to a minimum. Though the monitoring framework was
designed to work with the Performance Optimization feature pack, it can still be used with the default workloads that
are predefined for each database created.
Monitoring information is collected about the work performed by your applications and reported through table functions and
administrative views at the following three levels:
System level
These monitoring elements provide details about all work being performed on the system. Monitor-element access
points include service subclass, workload definition, unit of work, and connection.
Activity level
These monitor elements provide details about activities being performed on the system (a specific subset of the work
being performed on the system). You can use these elements to understand the behaviour and performance of
activities. Monitor-element access points include individual activities, and entries in the database package cache.


IBM Software
Data object level

These monitoring elements provide details about the work being processed by the database system within specific
database objects such as indexes, tables, buffer pools, table spaces, and containers, thereby enabling you to quickly
identify issues with particular data objects that might be causing system problems. Monitor-element access points
include buffer pool, container, index, table, and table space.
For database-wide control over the collection of monitoring data at the System, Activity and Data Object Levels, and the
generation of events in the new event monitors, ten database configuration parameters have been added. With the workload
management feature enabled, these controls can be enforced at both the database and at activity levels defined in workloads.
In this short exercise you will learn how to look at a database configuration file, examine the configurations for the monitoring
framework, and then actually make a few updates to the lock monitoring configurations.
1. If you no longer have the terminal opened from the previous exercise, right click on the Gnome desktop (as in 3.1) and
open a new terminal window.
2. Enter the command to get and display the database configuration file. The new configurations will appear at the bottom
of the file’s listing under Monitor Collect Settings.
db2start
db2 get db cfg for db2pt | grep -i MON
Figure 5 – Getting the Monitor Parameters
The request (REQ), activity (ACT) and Object Metrics (OBJ) are all set on (BASE) by default, which means all metrics are
collected for all requests executed on the data server.
3. Next you are going to turn on maximum collection for lock wait and deadlock monitoring and set the threshold for
lockwaits to 3 seconds.
Lab Tip: Use the up arrow on your keyboard to recall commands.
db2 update db cfg for db2pt using mon_lockwait hist_and_values

db2 update db cfg for db2pt using mon_lw_thresh 3000000
db2 update db cfg for db2pt using mon_deadlock hist_and_values
4. Show the new database configurations You may want to “get db cfg show detail” and explain:


IBM Software
db2 get db cfg for db2pt
Figure 6 – Getting the Values Parameters
4.2 System Monitor Switches

If you use the Snapshot Monitor or any related interfaces you should make sure that your system monitor switches are set so
you can collect the monitoring data you are after. The system monitor switches can be turned on at the instance level by
updating the database manager configurations. They can also be controlled at the session level. Each monitoring application
has its own logical view of the monitor switches (and the system monitor data). Upon startup, each application inherits its
monitor switch settings from the parameters in the database manager configuration file (at the instance level). A monitoring
application can alter its monitor switch settings with the UPDATE MONITOR SWITCHES USING MONSWITCH OFF/ON
command. The MONSWITCH parameter holds values found in the Monitor Switch column in the Snapshot Monitor Switches
table below. Changes to the switch settings at the application level affect only the application from which the switch was
changed.
Table 1. Snapshot Monitor Switches
Monitor Switch DBM Parameter Information Provided

BUFFERPOOL DFT_MON_BUFPOOL Number of reads and writes, time
taken
LOCK DFT_MON_LOCK Lock wait times, deadlocks
SORT DFT_MON_SORT Number of heaps used, sort

performance
STATEMENT DFT_MON_STMT Start/stop time, statement

identification
TABLE DFT_MON_TABLE Measure of activity(rows read/written)


IBM Software
UOW DFT_MON_UOW Start/end times, completion status
TIMESTAMP DFT_MON_TIMESTAMP Timestamps
This short exercise will teach you how to set and reset these controls.
1. By right clicking on the Gnome desktop (as in 3.1) open a new terminal window or you may use the one from 4.1 if
still open.
2. Connect to the database and list the system monitor switches from the database manager configuration file. You will
find most switches are set to OFF.
db2 connect to db2pt

db2 get dbm cfg | grep -i DFT_MON
3. Set monitor switches to ON and restart instance. Check new values.
db2 update dbm cfg using dft_mon_bufpool on

db2 update dbm cfg using dft_mon_lock on
db2 update dbm cfg using dft_mon_stmt on
db2 update dbm cfg using dft_mon_uow on
db2 update dbm cfg using dft_mon_sort on
db2 update dbm cfg using dft_mon_table on
db2 update dbm cfg using dft_mon_timestamp on
db2stop force
db2start
db2 get dbm cfg | grep -i DFT_MON
The monitor switches should be on now.
Figure 7 – Getting the Values Parameters
4. Now you will turn OFF the switch for bufferpools at the session level. It should currently be set to ON (session level),
adopted from the DFT_MON_BUFPOOL value in the db manager configuration file. First activate the database and take
a snapshot of the database, then turn the switch ON and look again to see that bufferpool metrics are being collected
for your session.
db2 get monitor switches

Notice that bufferpool is ON
db2 update monitor switches using bufferpool off


IBM Software
Set switch at session level

Notice that bufferpool is OFF
db2 activate database db2pt

Database must be active for monitoring
db2 get snapshot for bufferpools on db2pt

Notice how most metrics come up as Not Collected Database
db2 update monitor switches using bufferpool on

Updating session

Notice that the bufferpool is ON
db2 get snapshot for bufferpools on db2pt

Counters now contain numeric values, with probably a lot of zeros at this point, since there is little activity on the system.
This indicates that collection for these metrics is now active
5 Interfaces for database monitoring

Note: Your results may be a little different.
There are two ways to monitor operations in your database. You can view information that shows the state of various aspects of
the database at a specific point in time. Or, you can set up event monitors to capture historical information as specific types of
database events take place.
You can monitor your database operations in real-time using monitoring table functions. For example, you can use a monitoring
table function to examine the total amount of space used in a table space. These table functions let you examine monitor
elements and metrics that report on virtually all aspects of database operations using SQL.
5.1 CREATE EVENT MONITOR (change history) statement

Generally, the process of creating and using event monitors to capture information about the system when certain events occur
is similar for all event monitor types. First you create the event monitor, then you enable data collection, and finally, you access
the data gathered.
1. Create the event monitor. To create an event monitor, use the appropriate version of the CREATE EVENT
MONITOR statement. When you create an event monitor, you must choose how to record the data that the event
monitor collects. All event monitors can write their output to relational tables; however, depending on your specific
purposes, there are different options that might be more appropriate.

db2 "CREATE EVENT MONITOR EM_CHANGE_HIST
FOR CHANGE HISTORY WHERE EVENT IN (DBMCFG, DDLALL, DDLDATA, DDLSQL)
WRITE TO TABLE
CHANGESUMMARY (TABLE CHG_SUMMARY_HISTORY),


IBM Software
DDLSTMTEXEC (TABLE DDLSTM_HISTORY)

AUTOSTART"
The previous statement creates the following tables:
db2 "describe table chg_summary_history"

db2 "describe table ddlstm_history"
Changes the following parameters again
db2 update dbm cfg using dft_mon_bufpool off

db2 update dbm cfg using dft_mon_lock off
db2 update dbm cfg using dft_mon_stmt off
Figure 8 – Change of parameters
db2stop force
db2start
db2 "SELECT SUBSTR(appl_name,1,20)
appl_name,application_handle,event_timestamp, event_type,
substr(system_authid,1,20) system_authid FROM chg_summary_history"
Figure 9 – Show the change history
Changes the following parameters
db2 update dbm cfg using dft_mon_bufpool on

db2 update dbm cfg using dft_mon_lock on


IBM Software
db2 update dbm cfg using dft_mon_stmt on

db2stop force
db2start
db2 "SELECT SUBSTR(appl_name,1,20)
appl_name,application_handle,event_timestamp, event_type,
SUBSTR(system_authid,1,20) system_authid FROM chg_summary_history"
Figure 10 – Show the change history
Execute the follow script to generate the next objects:

• Table DOCUMENTS
• View V_DOCUMENTS
• Type name IMAGE.
edb2scripts
db2 -tvf create_objects_evm.sql
Figure 11 – Creation of Objects using DDL


IBM Software
db2 "SELECT event_id, event_timestamp, SUBSTR(event_type,1,20) event_type,

ddl_classification, SUBSTR(local_transaction_id,1,20) local_transaction_id,
SUBSTR(stmt_text,1,50) stmt_text
FROM ddlstm_history"
Figure 12 – Show the change history for Event Type DDLSTMEXEC
5.2 Identifying the statements that affect a table

Use usage lists to identify DML statement sections that affect a particular table when the statement sections execute. You can
view statistics for each statement and use these statistics to determine where additional monitoring or tuning might be required.
Do the following tasks:
1. Identify a table for which you want to view object usage statistics. You can use the MON_GET_TABLE table function to
view monitor metrics for one or more tables.
db2 update DATABASE CONFIGURATION using MON_OBJ_METRICS EXTENDED
Figure 2 – Set the mon_obj_metrics configuration parameter
2. Create an usage list for the table by using the CREATE USAGE LIST statement
db2 "CREATE USAGE LIST DOCUMENTSUL FOR TABLE DOCUMENTS"
3. Activate the collection of object usage statistics by using the SET USAGE LIST STATE statement
db2 "SET USAGE LIST DOCUMENTSUL STATE = ACTIVE"
4. During the collection of object statistics, ensure that the usage list is active and that sufficient memory is allocated for
the usage list by using the MON_GET_USAGE_LIST_STATUS table function. To check the status of the
DOCUMENTSUL usage list, issue the following command:
db2 "SELECT MEMBER, STATE, LIST_SIZE, USED_ENTRIES, WRAPPED
FROM TABLE(MON_GET_USAGE_LIST_STATUS('DOCUMENTS', 'DOCUMENTSUL', -2))"


IBM Software
Figure 3 – Status of the Documentsul usage list
5. Execute the follow script to create data

db2 -tvf create_data.db2
6. When the time period for which you want to collect object usage statistics is elapsed, deactivate the collection of usage
list data by using the SET USAGE LIST STATE statement.
db2 "SET USAGE LIST DOCUMENTSUL STATE = INACTIVE"
7. View the information that you collected by using the MON_GET_TABLE_USAGE_LIST function. You can view statistics
for a subset or for all of the statements that affected the table during the time period for which you collected statistics
db2 "SELECT MEMBER, EXECUTABLE_ID, NUM_REFERENCES, NUM_REF_WITH_METRICS,
ROWS_READ, ROWS_INSERTED, ROWS_UPDATED, ROWS_DELETED
FROM TABLE(MON_GET_TABLE_USAGE_LIST('DB2INST1', 'DOCUMENTSUL', -2))
ORDER BY ROWS_READ DESC
FETCH FIRST 10 ROWS ONLY"
Figure 4 – Information collected by using MON_GET_TABLE_USAGE_LIST
8. If you want to view the text of a statement that affected the table, use the value of the executable_id element in the
MON_GET_TABLE_USAGE_LIST output as input for the MON_GET_PKG_CACHE_STMT table function


IBM Software
db2 "SELECT SUBSTR(STMT_TEXT,1,40) STMT_TEXT

FROM TABLE
(MON_GET_PKG_CACHE_STMT(NULL,
x'01000000000000004F0000000000000000000000020020120402174639156732', NULL, -
2))"
Figure 5 – Text of statement that affected the table
9. Drop the objects generated for this lab.

db2 -tvf drop_objects_evm.sql
5.3 Creating event monitors that write to tables

There are different forms of this statement that you use, depending on the type of events that you intend to monitor. The table to
which the event monitor writes its output must be a non-partitioned table.
The various options for table event monitors are set in the CREATE EVENT MONITOR statement. For further assistance in
generating CREATE EVENT MONITOR SQL statements for write-to-table event monitors, you can use the db2evtbl command.
Simply provide the name of the event monitor and the required event type (or types), and the CREATE EVENT MONITOR
statement is generated, complete with listings of all the target tables. You can then copy the generated statement, make
modifications, and then execute the statement from the command line processor.
Formulate a CREATE EVENT MONITOR statement using the WRITE TO TABLE clause to indicate that event monitor data is to
be collected in a table (or set of tables).
The event type is one of the following values:
• ACTIVITIES
• BUFFERPOOLS
• CHANGE HISTORY
• CONNECTIONS
• DATABASE
• DEADLOCKS
• LOCKING
• PACKAGE CACHE
• STATEMENTS
• STATISTICS
• TABLE
• TABLESPACE
• THRESHOLD VIOLATIONS
• TRANSACTIONS
• UNIT OF WORK


IBM Software
1. To create a unit of work event monitor called myevmon, use a statement like the one that follows
db2 "CREATE EVENT MONITOR myevmon FOR UNIT OF WORK WRITE TO TABLE"
The preceding statement creates a unit of work event monitor that uses defaults for the logical groups of monitor elements
collected, the corresponding output table names, and the target table spaces for the table.
db2 "CREATE EVENT MONITOR evm_test FOR STATEMENTS WRITE TO TABLE"

Event monitors using the STATEMENTS event type collect data from the event_connheader, event_stmt, and
event_subsection logical data groups. Tables representing logical data groups that are specific to individual event types are
created, along with a control table for every write-to-table event monitor. For the event monitor test, created by user
db2inst1, the database manager creates the following tables:
• connheader_evm_test
• stmt_ test
• subsection_ test
• control_ evm_test
db2 "describe table connheader_evm_test"

db2 "describe table stmt_evm_test"
db2 "describe table control_evm_test"
db2 "set event monitor evm_test state 1"
2. Optional: Specify the logical groups for which you want data collected. By default, event data is collected for all logical
data groups for the event monitor type. (See Target tables, control tables, and event monitor table management for
details.)
If you want only data for selected logical groups collected, you can specify the names of the logical groups to include in
the CREATE EVENT MONITOR statement. For example, with a locking event monitor, you might want to collect only
the information associated with the LOCK and PARTICIPANT logical groups. To include only these logical groups, you
could use a statement like the one that follows:
db2 "CREATE EVENT MONITOR mylocks FOR LOCKING WRITE TO TABLE

LOCK,LOCK_PARTICIPANTS"
3. Execute the next scripts to see the event monitor statement
db2 -tvf create_objects_evm.sql

db2 -tvf create_data.db2


IBM Software
Figure 6 – Creation of Objects and generation of data
db2 "select * from connheader_evm_test"
Figure 7 – Logical Data Grouping connheader
db2 "select substr(EVENT_MONITOR_NAME,1,20) EVENT_MONITOR_NAME,

substr(MESSAGE,1,20) MESSAGE, substr( MESSAGE_TIME,1,20) MESSAGE_TIME from
control_evm_test"


IBM Software
Figure 8 – Logical Data Grouping stmt
db2 -tvf drop_objects_evm.sql
5.4 Displaying a list of event monitors created in your database

You can see what event monitors are already defined in your database. To view a list of the event monitors that you defined on
your system, query the catalog view SYSCAT.EVENTMONITORS.
db2 "SELECT SUBSTR(EVMONNAME,1,20) AS EVMON_NAME, TARGET_TYPE,

SUBSTR(OWNER,1,20) OWNER FROM SYSCAT.EVENTMONITORS"
Figure 20 – Event monitors defined in the database
You can also use a catalog view to see which event monitors exist for monitoring a specific type of event. The
SYSCAT.EVENTS view returns a list of event monitors and the type of events for which they record data.
db2 "SELECT SUBSTR(TYPE,1,20) AS EVENT_TYPE, SUBSTR(EVMONNAME,1,20) AS

EVENT_MONITOR_NAME FROM SYSCAT.EVENTS ORDER BY TYPE"


IBM Software
Figure 29 – Event monitor for a specific type of event
5.5 Event Monitor Data Retention from Release to Release

You can upgrade event monitor output tables after you upgrade the DB2 product. This capability lets you retain any data that
might exist in event monitor tables that you had before you upgraded.
As event monitors are enhanced in the DB2 product, the tables they produce might change. For example, new columns might be
added to a table for reporting new monitor elements. Before Version 10, if you had existing event monitors that wrote to tables
that contained data that you wanted to retain, and you wanted to collect the data in the newly-added columns, you were required
to manually alter them after upgrading to the new release. This alteration involved adding any of the new columns that you might
want to use. If you did not add the new columns, the event monitor would work as it had in the previous release, capturing only
the data supported by that the event monitor in that release.
Unformatted event tables that had changed could not be upgraded at all; you were required to drop them and then re-create
them.
The EVMON_UPGRADE_TABLES stored procedure upgrades the definitions of existing event monitor tables to match those
produced by the current level of the DB2 product. This feature lets you keep any existing tables that you might have, along with
all the data they contain, eliminating the need to manually alter, or to drop and re-create tables.
Note: Starting in Version 10, you can also use the ALTER EVENT MONITOR statement to add new logical groups to an event
monitor. You can use this approach as an alternative to EVMON_UPGRADE_TABLES to add logical data groups added in a
new release. However, you cannot use ALTER EVENT MONITOR to modify logical groups that are already associated with the
event monitor; if a logical data group already associated with the event monitor has changed, the only way to modify the event
monitor is using the EVMON_UPGRADE_TABLES procedure.
The EVMON_UPGRADE_TABLES procedure works with both regular and UE tables. For regular tables, the procedure adds
any new columns needed, drops old columns that are no longer required, and alters any columns as needed. For UE tables, the
procedure adds new columns and modifies existing columns as needed to allow the UE table to be processed by the
db2evmonfmt tool, or the EVMON_FORMAT_UE_TO_TABLES or EVMON_FORMAT_UE_TO_XML routines.
For example, a user created the following event monitors in DB2:
db2 "create event monitor lock for locking write to unformatted event table"
db2 "create event monitor act for activities write to table control"
db2 "create event monitor stat for statistics write to table"
db2 "create event monitor conn for connections write to table"


IBM Software
After upgrading the database to the current release they upgrade all the event monitor tables using the following command:
db2 "call evmon_upgrade_tables(null, null, null, ?, ?, ?)"
Note: The Parameter Value is 0
Figure 22 – Upgrade all the event monitor tables
If instead they only wanted to upgrade act, they could use this command:
db2 "call evmon_upgrade_tables(null,'ACTIVITIES', null, ?, ?, ?)"
Figure 10 – To update only activities


IBM Software
Alternatively they could choose to upgrade only the statistic event monitors by using this command:
db2 "call evmon_upgrade_tables(null,'STATISTICS', null, ?, ?, ?)"
Figure 11 – To update only statistics
6 Monitoring Current Activity

Even when you have set up monitoring and diligently followed all the steps to keeping your system performing well, inevitably
you will encounter a performance issue, typically identified when an alert is issued or when application response times are
noticeably slower. You may need to quickly figure out what activity is causing a problem and moreover, figure out why it is
problematic and recommend a solution.
This is when you go into triage mode. You need to investigate, quickly identify, and prioritize any potential activities that may be
contributing to a slowdown. You may have alerts set up or monitoring data that you have collected, but they may prove
inconsequential to the situation at hand, often taking significant time to format, sequence, and analyze. There are several key
areas to check on when trying to determine what is going on with your slow or unresponsive database system, start by asking
and answering a few simple questions.
• Are there more users on the system?
• Are there locking problems occurring?
• What is the overall state of the database?
• Are statistics current?
• What is status and usage of tablespaces and their containers?
• Are bufferpools being used efficiently?
• Is there excessive sorting or sort overflows happening?
• Is the database accepting new connections? remotely? locally?
• Have changes been made to the system?


IBM Software
In these exercises you will practice several methods to acquiring insight into “what is happening?” on your database system. By
doing this, you will gain a better understanding as to what activities can adversely affect performance and some of the options
available for gathering basic performance information.
6.1 Applications
APPLICATIONS: Here you will start a workload to generate some activity on the system and learn how to gain insight into what
applications are running and what they are doing.
1. Open up two terminal sessions one will be referred to as the “DB2 terminal” the other the “Workload Expert terminal”.
2. From the Workload Expert terminal: enter the alias that will put you in the correct directory and start the scenario.
cd /home/db2inst1
. .bashrc
edb2scripts
./we_run_live_random.sh
This will start the Workload Expert in graphical mode, which is required by this scenario. Wait for the scenario to give the
indication that it has started and is actually running. The appearance of the Live Connection Control is when you know it has
started successfully.
Figure 12 – Executing Workload Expert
• Minimize the workload expert window and terminal.


IBM Software
3. For the rest of the exercise enter the commands from the DB2 Terminal:
db2 list applications for database db2pt
Notice the various connection attributes being displayed especially the Appl. Handle and the Application Id. These are
often used as identifiers when looking at actual application activity or looking at locks conflicts.
Figure 13 – List of Applications
db2 list applications for database db2pt | grep DB2INST1 | wc
This is a simple way to count how many applications are connected. Here you have qualified the lines to count with the grep of
DB2INST1 and used the wc (word count) utility to count the lines, words, and characters of the piped output. The first figure
reported is the number of applications connected.
Figure 14 – List of Applications Connected
db2 list applications for database db2pt show detail | more

Most important here is the addition of the application’s status (monitoring element = appl_status). Additionally, you can use a
filtering command like grep to find out how many agents are “Executing” or in a “Lockwait” status.


IBM Software
Figure 15 – Status of Applications
db2 list applications

Make a note of an Application Id connected to the database
Examples: 127.0.0.1.45299.120623010213 or *LOCAL.db2inst1.120623010107
Lab tip: you can select, copy, and then paste Application IDs from the terminal
db2 get snapshot for application applid <your_applid> | more

Please remember to substitute your_applid with the Id of the application you want to look at.
Using the spacebar to page through the results, see if you can find how many locks are being held, or perhaps how many sorts
have been performed.
Figure 16 – Details of a Specific Application


IBM Software
*************Administrative view SYSIBMADM.APPLICATIONS**************
Here you will use an administrative view to retrieve information on connected applications. Any information that you get from
using the “get snapshot” command can be obtained via SQL with corresponding administrative views.
• conndb (aliases db2 connect to db2pt)
db2 "select agent_id, substr(appl_name,1,10) as appl_name,

substr(authid,1,20) as authid, appl_status from sysibmadm.applications where
db_name = 'DB2PT'"
List information for all active applications connected to DB2PT
Figure 30 – List Information for All Active Applications
**********************************DB2PD****************************************
The db2pd command can yield deep insight into application activity as well as many other critical monitoring objects like
bufferpools, tables, tablespaces, memory sets, and transactions. With the db2pd command you can get information on individual
threads or produce a stack trace for all engine dispatchable units (consisting mostly of threads). The db2pd command’s results
takes some practice to get used to, but can supply very valuable information and insight as to what is currently happening on a
system. It has been expanded to include workload management objects like service classes, work action sets, and work class
assets.
db2pd -db db2pt -applications | more

Use the Space bar on your keyboard to go through the result pages


IBM Software
Figure 31 – Details Information for All Applications
Here you see some familiar data like AppHandl, Appid, and Status with several other IDs used as keys to other db2pd inquiries.
This is merely a very simple sample of what this command can do.
Now you will use db2pd to determine which edu, engine dispatchable unit, primarily threads, are consuming the most CPU
cycles. This can be a valuable diagnostic tool when you start with just the knowledge that a CPU bottleneck has arisen.
db2pd -db db2pt -edus | more
Alternatively, you could also issue the following command instead:
db2pd -edus |more
Use the space bar on your keyboard to go through the result pages
Figure 317 – List Engine Dispatchable Unit
You can leave the Workload Expert scenario running and the DB2 Terminal open to continue with lab exercises.


IBM Software
6.2 System Perspective

The MON_GET_CONNECTION table function returns metrics for one or more connections.
The metrics returned by the MON_GET_CONNECTION table function represent the accumulation of all metrics for requests that
were submitted by a connection. Metrics are rolled up at unit of work boundaries, and periodically during the execution of
requests. Therefore, the values reported by this table function reflect the current state of the system at the time of the most
recent rollup. Metrics are strictly increasing in value. To determine the value of a given metric for an interval of time, use the
MON_GET_CONNECTION table function to query the metric at the start and end of the interval, and compute the difference.
Tip: As a connection can be mapped to more than one service superclass during its lifetime, the metrics reported through the
MON_GET_CONNECTION table function might represent a subset of the metrics for all requests submitted over the connection.
This might occur if metrics collection is disabled for some of the superclasses that are mapped by the connection.
The MON_GET_CONNECTION table function returns one row of data per connection and per member. No aggregation across
members (for a service class or more), is performed. However, aggregation can be achieved through SQL queries.
Display connections that return the highest volume of data to clients, ordered by rows returned.

db2 "SELECT application_handle, rows_returned, tcpip_send_volume,
evmon_wait_time, total_peas, total_connect_request_time
FROM TABLE(MON_GET_CONNECTION(cast(NULL as bigint), -2)) AS t
ORDER BY rows_returned DESC"
Figure 18 – List highest volume of data to clients
6.3 Data Object Perspective

The MON_GET_CONTAINER table function returns monitor metrics for one or more table space containers. The
MON_GET_CONTAINER table function returns one row of data per container and per database member. Data can be returned for
all containers in a given table space, or for all containers in the database. No aggregation across database partitions is
performed. However, aggregation can be achieved through SQL queries.
Metrics collected by this function are controlled at the database level using the mon_obj_metrics configuration parameter. By
default, metrics collection is enabled.
List utilization of container file systems, ordered by highest utilization


IBM Software
db2 "SELECT varchar(container_name, 65) as container_name, SUBSTR(fs_id,1,10)

fs_id, fs_used_size, fs_total_size, CASE WHEN fs_total_size > 0
THEN DEC(100*(FLOAT(fs_used_size)/FLOAT(fs_total_size)),5,2)
ELSE DEC(-1,5,2) END as utilization
FROM TABLE(MON_GET_CONTAINER('',-1)) AS t ORDER BY utilization DESC"
Figure 19 – List utilization of container file systems, ordered by highest utilization
6.4 Monitor Elements

The next query lists the activity on all tables accessed since the database was activated, aggregated across all database
members, ordered by highest number of reads.
db2 "SELECT varchar(tabschema,20) as tabschema, varchar(tabname,20) as

tabname, sum(rows_read) as total_rows_read, sum(rows_inserted) as
total_rows_inserted, sum(rows_updated) as total_rows_updated,
sum(rows_deleted) as total_rows_deleted
FROM TABLE(SYSPROC.MON_GET_TABLE('','',-2)) AS t
GROUP BY tabschema, tabname
ORDER BY total_rows_read DESC"
Figure 35 – List one row of data per database table and per database member


IBM Software
6.5 Activity Perspective

Here you will use a table function that returns a point-in-time view of both static and dynamic SQL statements in the database
package cache.
There is an optional input argument (either "D" or "S") of type CHAR(1) that specifies information type for the returned statement.
If the argument is NULL or an empty string, information is returned for all SQL statements. Not case sensitive: "D" stands for
dynamic; "S" for static.
db2 "SELECT MEMBER, SECTION_TYPE, TOTAL_CPU_TIME/NUM_EXEC_WITH_METRICS as

AVG_CPU_TIME, EXECUTABLE_ID FROM TABLE(SYSPROC.MON_GET_PKG_CACHE_STMT('D',
NULL, NULL, -2)) as T WHERE T.NUM_EXEC_WITH_METRICS <> 0 ORDER BY
AVG_CPU_TIME"
List all the dynamic SQL statements from the database package cache ordered by the average CPU time.
Figure 36 – List all the dynamic SQL statements
6.6 Statistics
The DB2 optimizer evaluates the data in your databases to develop access plans as efficiently as possible (using minimal
resources) to return a queries result set. If statistics have not been run or are inaccurate, your system will run a less-than-
optimal level. Statistics can make a huge impact on performance. One quick and easy way to get a picture on how recently
statistics have been run is to query the syscat.tables view. In this very short exercise you will practice querying the system
catalog views. The system catalog views represent both the statistics on tables and indexes along with the metadata of all
database objects that DB2 uses. You will then update the statistics and query again to see the results.
1. By right clicking on the Gnome desktop (as in 3.1) open a new terminal window.
2. You will run a script to create a schema (RSTATS), and a table with a single index (primary key). From the open
terminal:


IBM Software
edb2scripts
conndb
db2 -tvf createRSTATS_T1.db2
Now you will run a script that will query both the SYSCAT.TABLES and SYSCAT.INDEXES views to check to see if statistics
have been run. At this point the STATS_TIME should be null “-“, indicating statistics have not been run. Then you will update
the statistics for the table and see that the STATS_TIME has been updated to reflect the latest statistics update. From the same
terminal:
db2 –tvf checkTableIndexStats.db2

db2 runstats on table rstats.t1 for indexes all
db2 –tvf checkTableIndexStats.db2
Figure 20 – Statistics For Tables and Indexes
db2 terminate
• Close all terminal sessions and the Workload expert scenario


IBM Software
7 System Bottlenecks
Monitoring your database system at the system level and identifying bottlenecks can help provide clues as to where to look for
tuning opportunities.
7.1 I/O wait

In this exercise you will run a workload that results in a disk bottleneck. You will use vmstat to detect the disk bottleneck by
looking at the CPU wait time. Generally, if you see wait times here in excess of 25% you have an opportunity to improve overall
throughput by reducing the overall I/O burden on the containers being taxed. There are a number of ways to do this including
tuning SQL, using specialized database objects like Materialized Query Tables, or spreading the data being accessed across
more physical devices.
In this exercise, you will proceed as if you have a range partitioned table that is created in a single tablespace. You will run a
scenario that will create such a table and create I/O against it, after which, you will collect information like how many physical
reads are occurring on the tablespace and how much read time is accumulating against the underlying container. Then you will
run the same scenario, except the table is spread across two tablespaces. You will see how I/O gets spread and hopefully
realize the benefits gained by spreading data across different resources. All the while, you will be running the system
monitoring tools iostat and vmstat. You will learn what to look for to identify excessive I/O with these tools.
A note on spreading data across resources: There are a number of ways to “spread” data out to maximize I/O potential.
Range partitioning is only one technique you can use to spread your data out across disk resources. It should be noted that
range partitioning is primarily employed for a number of reasons, outside its potential to spread data. For instance, it also allows
for the seamless rolling-in and out of data since each range is contained physically in its own file. It also improves performance
through a feature called partition elimination. This occurs when a query includes the partitioning key as part of the searchable
predicate; the DB2 optimizer is made aware of the partitioning and can eliminate ranges that are not part of the query. Of course,
spreading data with range partitioning will not improve performance unless the tablespace containers have dedicated disk
resources assigned; its use in this lab is more for demonstrative purposes than to advocate a preferred technique of spreading
data.
Best practices dictate that spreading data starts with striping at the storage system level. You can create stripe sets across
multiple disks and build your file systems or logical volumes on top of these. Another approach is to present additional disk
resources to the database system. Then create new file systems or logical volumes on the new disk resources. It is more
effective to stripe at the lowest level possible. This exercise emphasizes using system monitoring tools to identify bottlenecks as
part of your approach to investigating and monitoring DB2 systems for performance issues.
1. Open up three terminal sessions. One will be referred to as the “vmstat terminal”, the second as the “iostat terminal”,
and the third as the “Workload Expert terminal”.
2. From the vmstat terminal: Start the vmstat tool with a 2 second interval.
vmstat 2
Take note of the cpu/wa column, this represents %cpu time in wait
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------

r b swpd free buff cache si so bi bo in cs us sy id wa st
1 1 5828 44320 21152 476860 0 0 4 4800 1609 3490 7 69 0 25 0


IBM Software
3. From the Iostat terminal: Start the “iostat tool” with a 2 second interval
iostat 2
4. From the Workload Expert terminal: Start the RangeNoSpread.scn workload scenario. This will take about a minute
to prepare and run for about a minute there after. Once running switch your focus to the vmstat and iostat terminals
output, where you should see high CPU wait times, well in excess of 25%. This is indicative of a disk bottleneck.
cd ~
. .bashrc
edb2scripts
db2stop force
db2start
./we_run_RangeNoSpread.sh
Watch the vmstat and iostat terminals to see the high CPU wait time being registered
Note: When you see this output in the WE console the scenario is done setting up and starting the actual workload.
USER> Database Control initialized (Executor0).

USER> COMPLETED: Preparation SQL (WE_0G0G0)
VMSTAT
Figure 21 – %CPU Time in Waiting


IBM Software
IOSTAT
Figure 22 – %CPU Waiting
5. Once the scenario has finished, from the Workload Expert terminal: Connect to the database and take a snapshot of
the tablespaces. Note how many physical reads are being done against the TS_RANGE1 tablespace. Then run the
script that will get the read times on a per container basis. You can compare these results with the results from the
second scenario.
conndb
db2 get snapshot for tablespaces on db2pt | more
Figure 40 – Physical Reads in a Tablespace
db2 –tvf HighestReadTimePerContainer.db2


IBM Software
Figure 41 – High Read Time Per Tablespace
6. Clean up the data objects created in the scenario. This will drop the objects created in the “No Spread” scenario.
Then you will run the same scenario except that the ranges will be dedicated to separate tablespaces and underlying
containers. This will result in the I/O being spread out across containers. You can compare these results with the
original results. The total number of I/O’s should be very close but spread out onto different containers.
Note: Since actual disk resources for both containers are the same, you will not see a big difference in CPU Wait time
(maybe a little bit, attributed to multiple prefetchers working). The emphasis here is that you will see that the I/O is indeed
being spread between the containers with a snapshot of the tablespaces and the MON_GET_CONTAINERS table function.
db2 -tvf cleanRange.db2

db2 terminate
db2stop force
db2start
./we_run_RangeSpread.sh
• Switch your attention to the Monitoring terminals to see the high wait time being registered in the
vmstat output


IBM Software
vmstat
Figure 42 – High Wait Time
conndb
db2 get snapshot for tablespaces on db2pt | more
Figure 23 – Physical Reads in a Tablespace range1


IBM Software
Figure 24 – Physical Reads in a Tablespace range2
Figure 25 – High Read Time Per Tablespace
7. Finally, clean up the objects created in the scenario and close all terminals.
db2 -tvf cleanRange.db2
• Close all terminals and processes. Use Ctrl+c to break out of vmstat and iostat.


IBM Software
8 Monitoring Database I/O

One of the most important things to monitor on a regular basis, if not the most important, is I/O activity. Excessive I/O activity
results from many different database operations; table and index scans, mismanaged or lack of memory to relieve I/O sort
overflows, batch activity, excessive logging, temporary tables, lack of sufficient resources, and poor database designs, are some
typical causes.
In the following exercises, you will use both the monitoring table functions and snapshot monitoring tools to help identify
potential and actual “I/O hot spots”.
It is a good idea to transition from snapshots to the monitoring framework wherever and whenever practical. It represents the
future of DB2 monitoring, however it should be noted that if you collect metrics for both you will incur overhead for both
monitoring streams.
Before you start, familiarize yourself with some of the important DB2 monitoring elements that report on I/O. The following table
represents some of these monitoring elements.
Monitoring Element Description/Use

Rows_Read Not the number of Rows_Returned but
the number read in order to fulfill
request. This element helps you
identify tables with heavy usage for
which you may want to create
additional indexes.
Rows_Returned The number of rows that have been
selected and returned to the
application. Use this number in
relation to Rows_Read to establish
reading efficiency factor. Can also be
used to help extrapolate network traffic
in a tiered application architecture.
Overflow_Accesses The number of accesses (reads and
writes) to overflowed rows of this table.
Overflowed rows indicate that data
fragmentation has occurred. If this
number is high, you may be able to
improve table performance by
reorganizing the table using the
REORG utility, which cleans up this
fragmentation.
A row overflows when it is updated

and no longer fits in the data page
where it was originally written. This
usually happens as a result of an
update of a VARCHAR or an ALTER
TABLE statement.


IBM Software
Rows_Written This is the number of rows changed

(inserted, deleted or updated) in the
table. A high value for table-level
information indicates there is heavy
usage of the table and you may want
to use the Run Statistics (RUNSTATS)
utility to maintain efficiency of the
packages used for this table.
Direct_Reads Reads that do not use the bufferpool:
LOBS, LONG VARCHAR, backups.
Enable filesystem caching on
tablespaces for LOB and Long data to
reduce overhead of direct reads.
Direct_Read_Time Time in milliseconds elapsed during
direct read operations
Direct_Read_Requests The Number of requests to perform a

direct read of one or more sectors of
data.
Pool_Data_P_Reads Indicates the number of data pages
read into bufferpool from the
tablespace containers (physical) for
regular and large tablespaces.
Pool_Index_P_Reads Indicates the number of index pages
regular and large index tablespaces.
Pool_Temp_Data_P_Reads Indicates the number of data pages
temporary tablespaces.
Pool_Temp_Index_P_Reads Indicates the number of index pages
temporary index tablespaces.
8.1 Snapshot on Database for I/O indicators
1. Open up two terminals sessions. One will be referred to as the “DB2 terminal” and the other as the “Workload Expert
terminal”.
2. From the DB2 terminal: stop and start the instance. This will reset all counters for both monitoring streams. Connect to
the database.
db2stop force
db2start
3. From the Workload Expert terminal enter the alias that will put you in the correct directory and start the scenario.
cd ~


IBM Software
. .bashrc
edb2scripts
This will start the Workload Expert in graphical mode, which is required by this scenario. Wait for the scenario to give the
indication that it has started and is actually running. The appearance of the Live Connection Control is when you know it
has started successfully.
Figure 26 – Workload Expert
• Minimize the Workload Expert display and terminal once started.
At this point we can practice monitoring I/O related metrics.

4. From the DB2 Terminal; you will take a snapshot of the entire database that will retrieve I/O metrics resulting from read
activity.
db2 get snapshot for database on db2pt | egrep -i 'read|rows|timestamp' |
more


IBM Software
Figure 27 – I/O Related Metrics
First take note of which is the later timestamp, the first database connect timestamp or the Last reset timestamp, the later
one represents when counters started for these data points. This is a simple and quick way to check on read activity on
your database. You can quickly compare the number of physical to logical reads, evaluate the number of direct reads, and
gauge how much Insert, Update, Select, and Delete activity has been going on.
You can use corresponding, snapshot based, administrative views and table functions to collect this data into relational
tables for further comparisons and analysis (SYSIBMADM.SNAPDB and SNAP_GET_DB).
In the subsequent exercises you will enhance some of the basic monitoring elements by calculating ratios from the base
monitoring counters.
5. Cancel the workload by clicking on the Cancel button under the Scheduler Manager window of the Workload Expert
graphical interface. Once the scheduler has been terminated, clic “X” out of the window closing the Workload Expert.
Respond YES to any prompts alerting you to the fact that the application has stopped processing (due to the cancel).
6. Close the open terminal.
8.2 Evaluating Read Efficiencies

In this exercise you will look at three key metrics that will help you identify how efficiently requests are being handled and where
physically on your system, the most time is being spent on reads.
The first metric you will capture is Reads per Transaction. You will run the SQL in the reads_per_trx.db2 file to get results.
The administrative view SYSIBMADM.SNAPDB is used here to calculate the average number of rows read per each transaction
from applications connected to the database.
This is a very high level monitoring view. It is best used when initially assessing a system or for trending I/O usage. These same
monitoring elements can use at more granular levels when taking application level snapshots.
The next ratio is the number of Rows Read to the Number of Rows Returned it is somewhat similar to reads per transaction in
that it is measuring read efficiency, looking to see how many rows need to be read for each row that is actually returned to the
application. You will run the SQL in the rread_per_rrtrn.db2 file to obtain results. The monitoring table function
MON_GET_WORKLOAD() is used as the basis to the query.


IBM Software
Lastly, you will look at the Highest Read Time per Container. This will help you determine where I/O time is being spent. It will,
in part, verify if your physical layout works well with respect to the activities on your database. You will run the SQL in the
HighestReadTimePerContainer.db2 file. The monitoring table function MON_GET_CONTAINER() is used as the basis to the
query.
{By looking at the number of rows read per rows returned ratio you might assess that additional indexes are required. The read
time per container can tell you physically where the most time is being spent on reading and may assist you in determining if and
where more containers are needed for your tablespaces and which tablespaces, including temporary tablespaces are the
busiest.}
You can continue using same terminal sessions from 8.1.

1. From the DB2 Terminal; You will collect more monitoring metrics indicative of I/O related activities by running SQL
based scripts. First Reads per Transaction.
edb2scripts
conndb
db2 -tvf reads_per_trx.db2
reads_per_trx.db2: in this screen shot you see a result of 110 reads/trx, a fairly good rate for an OLTP system. Under 10 would
be very good, over 50 worth investigating.
Figure 28 – Read Per Transaction
2. Now get a picture of the rows read for every row returned to the applications.
db2 –tvf rread_per_rrtrnd.db2
rread_per_rrtrnd.db2: Since we are using the monitoring framework, statistics are aggregated at the workload level, in this
case even without the workload management feature being used the default system workloads are available to query.


IBM Software
Figure 29 – Rows Read For Every Row Returned
3. Finally, find the highest read time per container. This will indicate which containers and tablespaces are being heavily
utilized.
HighestReadTimePerContainer.db2: Here it is quite easy to see which tablespace’s underlying containers have the
highest read time. Keep in mind that this is done on a per container basis so this would be a great way to evaluate how well
data is spread with respect to the requests being made, with the basis of evaluation being actual usage, as opposed to
counting rows or looking at data statistics and assuming equal usage.
Figure 50 – Highest Read Time By Tablespace
8.3 SNAPDB ADMINISTRATIVE VIEW

Retrieve the status, platform, location, and connect time for each database member of the currently connected
database.
db2 "SELECT SUBSTR(DB_NAME, 1, 20) AS DB_NAME, DB_STATUS, SERVER_PLATFORM,
DB_LOCATION, DB_CONN_TIME, DBPARTITIONNUM FROM SYSIBMADM.SNAPDB ORDER BY
DBPARTITIONNUM"


IBM Software
Figure 51 – Status, platform, location, and connect time by member
8.4 SNAP_GET_DB TABLE FUNCTION

Retrieve the status, platform, location, and connect time as an aggregate view across all database members for all
active databases in the same instance that contains the currently connected database.
db2 "SELECT SUBSTR(DB_NAME, 1, 20) AS DB_NAME, DB_STATUS, SERVER_PLATFORM,

DB_LOCATION, DB_CONN_TIME FROM TABLE(SNAP_GET_DB(CAST (NULL AS VARCHAR(128)),
-2)) AS T"
Figure 52 – Status, platform, location, and connect time as an aggregate view of all members
• Close the open terminal.


IBM Software
9 Monitor and Tune Bufferpools

Bufferpools are real memory heaps used to cache pages of data and indexes read in from disk resources. When comparing
access times between memory and disk we are talking about nanoseconds vs. milliseconds, since memory is a much faster
resource. You can monitor and tune your bufferpools when necessary, or let STMM do it automatically for you.
9.1 Bufferpool Hit Ratios

In this exercise you will run a Workload Expert Scenario that will result in a low bufferpool hit ratio. In a second terminal, while
the workload is cycling, you will monitor hit ratios with both snapshot and the monitoring table functions. You will dynamically
increase the bufferpool until hit ratios are at an acceptable level. Finally, you will alter the bufferpool so that it becomes a
member of Self Tuning Memory Manager memory heaps.
You should be logged in as db2inst1

1. Open up two terminal sessions. One will be referred to as the “DB2 terminal”, the other as the “Workload Expert
terminal”.
the database.
db2stop force
db2start
3. From the Workload Expert terminal enter the alias that will put you in the correct directory. Then start the
BPMonTune.scn scenario. This scenario will not start the Workload Expert GUI ; it just runs in the terminal console.
cd ~
. .bashrc
edb2scripts
./we_run_BPMonTune.sh
(When you see “Completed: Preparation SQL” in the output you will know that the scenario has officially started)
USER> COMPLETED: Preparation SQL (WE_0G0G0)
4. From the DB2 terminal: Connect to the database and run the file that will calculate BP hit ratios for regular data with
both the snapshot monitor administrative view (SNAPBP) and one of the monitoring table functions
(MON_GET_BUFFERPOOL). SQL statements for both are in the same file; the first listing is the SNAPDB based query,
while the second uses the MON_GET_BUFFERPOOL table function.
edb2scripts
conndb
db2 -tvf get_bphits_all.db2
You can use the up key on your keyboard and re-enter the “db2 –tvf get_bphits_all.db2” command a few times to
inspect the output at different points in time.
5. Examine the output from each set of metrics. Note that the bufferpool hitratio is low for the BPMONTUNE bufferpool,
and make a note of what that value is and the number of logical reads that have been performed.
6. Still from the DB2 terminal: Alter the size of the bufferpool to 5000 and examine bufferpool metrics again. The
bufferpool will dynamically change size. You should see some improvement but you would probably like to see better.
(The longer the scenario has been running, the longer it will take to see improvement). Then alter the BPMONTUNE


IBM Software
bufferpool to 10000 pages. Soon after this change you should see hit ratios approaching/exceeding 90 %. Depending
how long the Workload Expert Scenario has been running, it may take a few minutes before the hit ratios reach such a
level.
db2 alter bufferpool bpmontune size 5000

db2 alter bufferpool bpmontune size 10000
You can repeat the “db2 -tvf get_bphits_all.db2” command to see changes in the hit ratio.
7. Finally alter buffepool to automatic. When you do so it will be dynamically tuned automatically by DB2’s Self Tuning
Memory Manager and its sophisticated algorithms.
db2 alter bufferpool bpmontune size automatic
db2 –tvf get_bphits_all.db2
8. From the Workload Expert terminal you will stop the running scenario by typing quit and the enter key.
quit
9. Close both terminals
Note: If cleanup fails for any reason and you wish to run the lab again, run the manual cleanup file: db2 –tvf
manual_cleanup_bpmontune.db2


IBM Software
10 Tools
Note: your results may be a little different.
You have learned about some of the essential DB2 monitoring elements, why they are important, and some of the DB2
interfaces available for monitoring performance related activities. It is possible to create your own scripts, applications, and
monitoring repositories with these interfaces but this can be a daunting task especially in larger environments. This is when you
start thinking about finding tools, tools that already make good use of DB2 monitoring interfaces. Tools offer many advantages
like logical groupings of related metrics, interactive design, and the ability to quickly save performance data for further analysis.
In this lab exercise you will learn about the db2top tool, which comes with DB2 on Unix/Linux installations.
10.1 DB2TOP
The db2top tool runs on and comes with Unix/Linux installations of DB2. You can look at both cumulative and delta
perspectives for a wide variety of metrics and activities including: Databases, Tablespaces, Bufferpools, Dynamic SQL, Locks,
Memory Pools and more.
In this exercise, you will start a workload with the Workload expert utility and examine what kinds of performance related activity
is occurring from a number of different views. Then we will look for expensive SQL, display and save the actual statement into a
file where it can be benchmarked and tuned with other db2 tools such as db2batch.
1. Open up two terminal sessions. One will be referred to as the “DB2 terminal”, the other as the “Workload Expert
terminal”.
the database.
db2stop force
db2start
3. From the Workload Expert terminal enter the alias that will put you in the correct directory and start the scenario.
cd ~
. .bashrc
edb2scripts
This command will start the Workload Expert in graphical mode and run a mixture of random SQL against the db2pt
database (Live SQL Mixer). It will take a minute or two before it is fully running. The Live Connection Control will appear
as shown below when fully running:


IBM Software
Figure 30 – Run a Mixture of Random SQL
4. Once you’ve seen that the scenario is running use the graphical controls, increase connections to around 5-10 for each
control this will make the workload a bit more substantial.
• Minimize the Workload Expert GUI window

• Minimize the Workload Expert terminal
5. From the DB2 terminal: Start the db2top facility and invoke the online help utility.
db2top -d db2pt
h
Note : command “h” is for help.


IBM Software
Figure 31 – Online Help Utility
Here you can see the various keystroke based options available. There is a wide range of objects, activities and
perspectives to choose from. There are also options relating to the display and behavior of the tool. Most notably, O is
used to look at current settings for db2top, k is used to toggle between actual and delta values and C enables the
capturing of the session into a file that can be replayed and thus reanalyzed.
6. Now you will explore some of the options first hand. First you will look at Tables (T), Bufferpools (b), and finally Dynamic
SQL (D).
• Use the Enter Key to exit Help.

• T to display the most active tables, you should see the Delta view which is representative of the activity
during a tuning interval.
• k to toggle to Actual view where cumulative results are seen.
Here you can see the most active tables and what kind of I/O is occurring.
• R to reset the snapshot counters then y, enter to confirm.
The Actual counters will be reset to zero.
• b to see Bufferpool activity including Bufferpool Hit Ratio.


IBM Software
Figure 32 – Bufferpool Activitie Incuding Hit Ratio
• D to see recent dynamic SQL activity against the database.

• f to freeze the screen.
• Pick out a query to “tune”. Use your mouse to highlight the SQL_Statement Hash Value and copy the
value on to the clipboard.


IBM Software
Figure 33 – Recent Dynamic SQL Activity
• Enter key to unfreeze the display.

• L to prompt for SQL_Statement Hash Value, paste previously copied value and Enter to bring up SQL
statement.
Figure 34 – Detail Information of SQL


IBM Software
• E to open a file for editing (vi editor is default).

• :w! mySQL.out (to write the SQL out to a file named mySQL.out).
• :q (to quit vi).
• q (to exit out of db2top).
Now you are at the terminal command prompt. You should be able to look at the mySQL.out file you created. It is ready
for further analysis and tuning. You will create a simple benchmark with the db2batch tool.
The mySQL.out file should be located in the directory you called db2top from, so you shouldn’t have to navigate to work
on the file.
Lab Note: you may need to enter clear to reset the terminal display (get rid of black).
• more mySQL.out (Check on contents of file).

• db2batch –d db2pt –f mySQL.out ( to invoke db2batch get benchmark results).
Figure 35 – Benchmark Result
Now you can see how long it takes for DB2 to process this query in CPU time. You could use other tools like the explain
utility or db2advis to further analyze and tune. You will use these tools in greater detail in the SQL Tuning Lab.


IBM Software
Note: The next section is only for 64 bits VM
11 Optim Performance Manager OPM

11.1 Installation of Optim Performance Manager (OPM) Software
To save time, we will not be performing an OPM installation here. It’s an easy process to follow after you get the software.
However, it is important to note the following.
• OPM is a web-based tool and therefore it uses an internal web console server.
• The OPM installation requires DB2 to be started on the same server prior to the install.
• The OPM installation process will create the PERFDB database, where performance management data will be
stored.
11.2 Create the SAMPLE Database
Before beginning the exercise, let’s create DB2’s SAMPLE database using the following command:
db2sampl
11.3 Start the OPM Web Console

1. First we need to start the OPM server, to do this you need to open a new terminal and log on with db2inst2 user and
use password as password.
su – db2inst2
2. Next, go to /opt/ibm/OPM directory.
cd /opt/ibm/OPM
3. Now you can start the server.
./OPMstart.sh
Note: This can take some minutes, you need to wait until the message “SERVER: ACTIVE” appears in the console as shown in the
next image:
Figure 59 – Starting OPM Server


IBM Software
4. Double click OPM Web Console icon on the desktop.
Figure 60 – OPM Web Console access
Note: Before to continue you need to be sure the instance is started, so in a new terminal window enter the command “db2start” to
start the database instance. Make sure the instance is started successfully. If you notice a message that says “The database manager
is already active”, that’s OK. Please close the terminal window and continue to the next step.
5. Type-in User name db2inst2 and password password in the login window and click Log In.
Figure 61 – OPM Web Console Log in


IBM Software
11.3.1 Delete Connections

Note: This section is only in the case that exist connections after open the OPM.
Follow all the next instructions:

1. Click the x to close the Extended Insight Dashboard tab
Figure 62 – Close Extended Insight Dashboard tab
2. In the Databases tab, click on the PERFDB database connection
Figure 63 – PERFDB connection
3. Click on the Delete button.
Figure 64 – Delete PERFDB connection


IBM Software
4. Click OK to confirm.
Figure 65 – Delete PERFDB connection
5. Click on the sample database connection.

6. Click on the Delete button.
Figure 66 – Delete sample connection
7. Click OK to confirm. [Please wait for finish to delete.]
Figure 67 – Delete sample connection
8. Click the x to close the Databases tab
Figure 68 – Close Databases tab


IBM Software
11.4 Manage Database Connections

1. In the Getting Started section (top right hand side), click Add and configure a database for monitoring to add and
configure monitored databases.
Figure 69 – OPM Getting Started section
2. Click Add… to add a database connection.
Figure 70 – OPM Add a database connection


IBM Software
3. Fill in the details for the Sample database. Click OK to add the connection.
Figure 71 – OPM Database connection

4. Click Configure Monitoring….
Figure 72 – OPM Configure Monitoring

Note: Please do not change Eastern Standard Time even though you might be in a different time zone. If you do so, all of the chart
data will be offset by a difference of hours since the database was created in the VM image in the Eastern Time zone. In other words,
you’ll see the chart to be blank.


IBM Software
5. Select the Use predefined template radio button and click the dropdown to select OLTP Production with all details. Click
Next.
Figure 73 – OPM Configure Monitoring values
6. On the next screen, click the pencil button next to Retention times and sampling intervals.
Figure 74 – Retention times and sampling intervals
7. Notice that you can modify the aggregation intervals in this screen to influence the retention period of the detailed data,
but this is not neccessary in this case. Click Cancel.
Figure 75 – Retention settings


IBM Software
8. Check the Workload Manager option in Monitoring profiles. Click on the pencil button next to Workload Manager.
Figure 76 – Workload Manager option
9. Change each collection interval to 3 minutes and click OK.
Figure 77 – Workload Manager settings

10. Click Next.
Figure 78 – Monitoring Functions/Views list


IBM Software
11. Click Next two times and click Finish. Fill in the password password and click OK.
Figure 79 – OPM Configure Monitoring finish
12. It may take a while to configure. Please be patient.
Figure 80 – Configure monitoring

13. Click Close.
Figure 81 – Configure monitoring close
14. Click the x to close the Databases tab.
Figure 82 – Close Databases tab
15. Now we need to create the table called OPM_SAMPLE_TABLE for use by the subsequent labs.
16. Open a new terminal window by right-clicking on the Desktop and choosing the “Open Terminal” item.


IBM Software
Figure 83 – Open in Terminal
17. Change the directory to /home/db2inst1/Documents/LabScripts/db2pt/essential/db2scripts/01INTRO.

cd /home/db2inst1/Documents/LabScripts/db2pt/essential/db2scripts/01INTRO
18. Run the INTRO01.SH script to create the OPM_SAMPLE_TABLE.
./INTRO01.sh
19. Close the terminal window.
20. Do not close the OPM Web Console as we will need it for the next lab.
11.4.1 Alerts Configuration and Notification

1. Click View alerts.


IBM Software
Figure 84 – View alerts

11.4.1.1 Configure Health Alerts
1. Click the Health Alerts Configuration tab.
Figure 85 – Health Alerts Configuration
2. Click Database Availability to select it. Click Edit...


IBM Software
Figure 86 – Database Availability
3. Specify password as password (just in case ask for it), click Log In.
Figure 87 – Verifying credentials
4. Through this Alert configuration, you will be notified if the database is not reachable or quiesced. [Note: We will not
change anything here.] Click Cancel.
Figure 88 – Edit Alert Parameters


IBM Software
Note: You can click some other Alert Type shown and click to select it and then click Edit to review. Please do not modify and click
Cancel.
Note: Just FYI: The Alert Configuration can also be done through the Health Summary dashboard as shown.
Figure 89 – Health Summary Dashboard
11.4.1.2 Configure Performance Alerts

1. Click the Performance Alerts Configuration tab.
Figure 90 – Performance Alerts Configuration
2. Click Connect. [Note: If you see YES instead of the Connect button, skip to the next step.]
Figure 91 – Database Connect
3. Click OK in the Connection Successful screen.

4. Check SAMPLE.


IBM Software
Figure 92 – Check SAMPLE
5. Select Buffer Pool Hit Ratio from the dropdown.
Figure 93 – Alert Name
6. Change Critical percentage to 70 and then change Warning percentage to 80.
Figure 94 – Update porcentages
7. Click Apply.
Figure 95 – Apply
8. Click OK in the Successful window.

9. Click the By Database tab.
Note: This tab allows you to configure one or more alerts for one database.
Figure 96 – By Database


IBM Software
Note: After changing one or more alerts for the current database, the same settings can be applied to another database using the
Copy Settings button. [Note: We will not change anything here].
The OPM allows you to manage performance alerts easily. It gives you the ability to:
1. Configure one alert and apply to one or more databases simultaneously.

2. Configure alerts for one database and apply that configuration to other database.
11.4.1.3 Alert Notification

1. Click the Alert Notification tab then click Select a Database dropdown. Select SAMPLE.
Figure 97 – Alert Notification
2. Click Configure Email and SNMP services.
Figure 98 – Configure Email and SNMP services
Note: Just FYI: You could have also clicked Open Services to open Email and SNMP services.
Figure 99 – Configure Email and SNMP services


IBM Software
3. Click Email service to select it. Click Configure.
Figure 100 – Email service configuration
4. In Configure the Email Service, the SMTP server information can be specified to enable email notifications. [We will not
change anything here.] Click Cancel.
5. Click SNMP to select it. Click Configure.
Figure 101 – SNMP configuration
6. Review the details and click Cancel.

Note: The OPM can send SNMP traps to your on-call scheduling system so that DBAs on call are sent the notifications.
7. Click x to close the Services tab.
Figure 102 – Close Services tab
8. Click Alerts tab.

9. Click Add.
Figure 103 – Add an Alert


IBM Software
10. Please notice that you can configure notifications for each alert separately for warning, critical or both using either email
or SNMP or both. This allows OPM to send different alerts to different people. [Note: We will not modify anything here.]
Figure 104 – Alert configuration
11. Click Cancel.

12. Click x to close Alerts.
Figure 105 – Close Alerts


IBM Software
11.5 Run Workload

1. Open two new terminal windows by right-clicking on the Desktop and choosing the “Open Terminal” item.
Figure 106 – Open in Terminal
2. Change the directory to /home/db2inst1/Documents/LabScripts/db2pt/essential/db2scripts/02CORE in both terminals.

cd /home/db2inst1/Documents/LabScripts/db2pt/essential/db2scripts/02CORE
3. Run the CORE01.SH script from the first terminal. This script will run 300 iterations using the DB2USER1 user id.
./CORE01.SH
Note: The script CORE01.SH will run a work load through a Java program with no retry for the deadlocks.
When you run this script, you will notice java exceptions being thrown for SQL error -911 indicating deadlocks between competing
transactions. This is by design and normal.
4. Run the CORE02.SH script from the second terminal. This script is the same as CORE01.SH except that it connects as
user DB2POWER.
./CORE02.SH
Note: If the workload stops before you complete this lab exercise, please restart it again.


IBM Software
11.6 Review Health Summary

1. Switch back to the OPM Web Console. Click View the health summary.
Figure 107 – View the health summary
2. The Health Summary information is presented for the following.

• Alerts
• System
• Database
Figure 108 – Health Summary

3. Click Recent 60 minutes dropdown to modify the refresh interval.
Figure 109 – Health Summary settings
4. Modify numbers 1 and 15. Click OK.
Figure 110 – Health Summary settings


IBM Software
5. In the Health Summary dashboard, you have the convenience of looking at the overall health of the configured
databases through a single screen as shown below. Based upon the alerts and warnings, you have the ability to drill
down further to explore any problem areas.
6. Please wait for a minute or two for the Critical Alerts number to go more than 50 if this is possible.
7. Click on the number shown under the Critical Alerts.
Figure 111 – Critical Alerts
8. Notice that the majority of the alerts are lock wait, which is expected due to -911 errors. Click Analyze.
Figure 112 – Analyze Alerts
9. Click the Participants tab. You can see Owner and Requester application causing the lock wait.
Figure 113 – Participants tab


IBM Software
10. Click the Statements tab. You can see the SQL statements from each application causing lock wait.
Figure 114 – Statements tab
11. Click x to close the Application Lock wait window.

12. Click x to close the Locking Alerts window.
11.6.1.1.1 Analyze Lock Wait

1. Click Open Locking dashboard.
Figure 115 – Locking dashboard
2. Click Select a Database. Select SAMPLE.
Figure 116 – Select a database
3. Review locking statistics for the SAMPLE database.


IBM Software
Figure 117 – Locking statistics
4. Click the Current Waiting Connections tab.
Figure 118 – Current Waiting Connections tab
5. Click the Current Blocking Connections tab. Select any lock wait.
Figure 119 – Current Blocking Connections tab
6. Click Analyze to open details on the locking issue for any selected lock wait.

IBM Software
Figure 120 – Analyze Locking
7. Click Close.
Figure 121 – Close Locking
8. Close the Locking dashboard
Figure 122 – Close Locking dashboard
11.6.1.1.2 Analyze Sort Overflows

1. Return to the Health Summary dashboard.
2. Click on the alert icon under Sorting.
Figure 123 – Sorting Alert

IBM Software
3. View the Sort and Sort Overflow diagrams. Click the Actions tab.
Figure 124 – Actions tab
4. Click Workload Dashboard.
Figure 125 – Workload Dashboard
5. In the Workload dashboard, check number of sorts per minute, sorts per transactions, total sort times, sort time, piped
sort and sort memory charts.

IBM Software
Figure 126 – Workload Dashboard charts (1)
6. While you are on the Workload dashboard, review the transaction, row and statement throughput at the database level.

IBM Software
Figure 127 – Workload Dashboard charts (2)
7. Close the Workload dashboard.
Figure 128 – Close Workload Dashboard
11.6.1.1.3 Analyze I/O Alerts

1. Click the Health Summary dashboard.
2. Click on the alert icon under I/O.
Figure 129 – I/O Alert
3. Review the alerts shown for Package and Catalog Cache Hit Ratio.

IBM Software
Figure 130 – I/O Alerts details
4. Click the Actions tab. Click Memory dashboard.
Figure 131 – Memory Dashboard
5. The memory dashboard shows memory heaps related to the Database Global Memory.
Figure 132 – Database Global Memory
6. Check the memory sizes for each and the related database parameter.

IBM Software
Figure 133 – Memory Dashboard details
7. Click on Scope dropdown. Explore Instance and Application memory scope.
Figure 134 – Explore Instance and Application memory scope
8. Close the Memory dashboard.
Figure 135 – Close Memory Dashboard
Note: Remember that we drilled down from overall health summary for all systems to a very specific problem notified through an
alert. This feature helps to pin point hot spots quickly.
9. Close the Health Summary dashboard.
Figure 136 – Close Health Summary Dashboard

IBM Software
11.7 Overview of a selected database

1. Click View the performance overview for a database
Figure 137 – View the performance overview...
2. On the Overview dashboard, you can focus on areas that are shown in red.
Figure 138 – Overview Dashboard
3. When you hover the mouse over a line, the Open Details icon becomes visible, which can be clicked to open the related
dashboard.

IBM Software
Figure 139 – Open Details icon
11.7.1.1.1 View Historical Data

1. You can view the past Overview details for the database by going back in history. Click on the time-control back arrow.
Figure 140 – Past Overview details
2. You can also drag the blue 1 Hour button backward on the timeline to see the past data.
Figure 141 – Timeline button
3. While viewing past data, the aggregation level indicates if you are viewing detailed or aggregated data.
Figure 142 – Aggregation level
Note: The aggregation levels were defined at time of adding the monitored database. The aggregation levels can be changed
through Open Database dashboard.

IBM Software
Figure 143 – Aggregation levels
11.7.1.1.2 View Real-Time Data

1. You can see the current state of the database by switching to the Real-Time Data view. Select Real-Time Data.
Figure 144 – Real-Time Data view
2. You can either choose for screen to refresh automatically through a chosen period (default 1 minute) or refresh it at any
time by clicking Refresh Now.
Figure 145 – Refresh Now option
3. Close the Overview dashboard.
Figure 146 – Close Overview dashboard
11.7.1.2 Connections to a database

1. Click View Connections to a database.

IBM Software
Figure 147 – View connections to a database
2. Click to uncheck Refresh Every. Make sure you are in the Real-Time Data view.
Figure 148 – Uncheck Refresh Every
11.7.1.2.1 View Overall Connection Details

1. Click Choose Columns.
Figure 149 – Choose Columns
2. Select these columns and uncheck all others.

Application Name, Session User, Latest Connection Status, Transactions, Lock Wait
Time, CPU Time, Wait Time, I/O Time
3. Click OK.

IBM Software
Figure 150 – Select Columns
4. Review your connections and notice CPU and different wait times.
Figure 151 – Review information
5. Click on a column header to sort the data in ascending or descending order.

6. Click to select any row to refresh the Connection Details.
7. Click the Overview tab to see the details of the selected connection.
Figure 152 – Overview tab

IBM Software
8. Click the Server Times tab.
Figure 153 – Server Times tab

9. Click the I/O tab.
Figure 154 – I/O tab
10. Review the Rows and Transactions, Locking and Communication and Utilities tabs.
Note: Through the connection details dashboard, you can see aggregated information at the connection level.
The next section shows the individual SQL details in a connection.

IBM Software
11.7.1.2.2 View SQL Details in a Connection

1. Click Show Executed SQL.
Figure 155 – Show Executed SQL
2. Click the Execution Summary tab. Click Refresh Now.
Figure 156 – Execution Summary tab
3. Click the Overview tab.
Figure 157 – Overview tab

IBM Software
4. Click the Server Execution Times tab.
Figure 158 – Server Execution Times tab
5. Click the I/O tab.
Figure 159 – I/O tab
6. Review the Row Activity and Locking and Communication tabs.

7. Click to close the SQL Statements and Connection dashboard.
Figure 160 – Close dashboards

IBM Software
11.7.1.2.3 View Current Application Connections

1. Click Open Current Application Connections dashboard.
Figure 161 – Current Application Connections dashboard
2. Click the Choose Columns icon.
Figure 162 – Choose Columns icon
3. Hide 4 columns as shown. Click OK.
Figure 163 – Hide columns
4. Click Dynamic Statements twice to sort in descending order.

IBM Software
Figure 164 – Review information
5. Click View SQL Details to see the currently running SQL.
Figure 165 – SQL Details
Note: Since our work load is OLTP like with short running queries, you will not be able to see actual SQL.
If you are running data warehouse type long running queries, you will be able to see them in this dashboard.
The next section shows the individual SQL details in a connection.
6. Click Close.
7. Close the Current Application Connections dashboard.

IBM Software
11.7.1.3 Buffer Pool and I/O

1. Click Open Buffer Pool and I/O
Figure 167 – Buffer Pool and I/O dashboard
2. Change the view to Real-Time Data.
Figure 168 – Historical Data
3. Click to select the OPM_SAMPLE_BP_1 buffer pool.
Figure 169 – OPM_DAMPLE_BP_ 1 buffer pool

IBM Software
4. Check Size and I/O Times in the details window.
Figure 170 – Detailed Information
5. Click the Hit Ratio and I/O tab.
Figure 171 – Hit Ratio and I/O tab
6. Select OPM_SAMPLE_BP_1 buffer pool. Click the button Show Contained Objects and the screen will
automatically switch to the Table Spaces tab with a filter on only table spaces for this buffer pool.

IBM Software
Figure 172 – Show Contained Objects
7. Select OPM_SAMPLE_TS_1 table space.
Figure 173 – Table Spaces tab
8. Check Size and I/O Times for this table space.
Figure 174 – Size and I/O Times tab

IBM Software
9. Click the Hit Ratio and I/O tab.
Figure 175 – Hit Ratio and I/O tab
10. Click Show Contained Objects.
Figure 176 – Show Contained Objects
11. The Tables tab shows tables contained in the table space OPM_SAMPLE_TS_1.
Figure 177 – Tables tab
12. Review Detailed Information for OPM_SAMPLE_TABLE.
Figure 178 – Detailed Information

IBM Software
13. Click Show SQL.
Figure 179 – Show SQL
14. The SQL dashboard shows only those SQL statements containing the OPM_SAMPLE_TABLE.
Figure 180 – SQL dashboard
15. Close the SQL Statements and Buffer Pool and I/O dashboards.
11.7.1.4 Reports
1. Click Run performance reports for a database. [Please wait for reports to load.]

IBM Software
Figure 182 – Run performance reports...
11.7.1.4.1 SQL Baseline Comparison Reports

1. Select SQL Baseline Comparison report from the dropdown.
Figure 183 – Select report
2. Please select the followings:

1. Select Period 1 start date 2 hours prior to the Period 2 start date.
2. Select 2 hours from Duration dropdown.
3. Select Highest 10.

IBM Software
4. Select Improvements and regressions.

5. Click Generate Report.
Figure 184 – Report parameters
Note: Please wait for the report to generate.
Figure 185 – Generating report
3. Review the report which is opened in a new tab in the browser.

IBM Software
Figure 186 – Report output
4. Close SQL baseline Comparison report tab.

5. Close the Reports dashboard.
Figure 187 – Close dashboard
6. Close the CORE01.SH and CORE02.SH workload terminal windows.

7. Log out from OPM Web Console.
8. Close Firefox window.
9. Stop the OPM Server. In a new terminal window :
su – db2inst2 (use password as password)
cd /opt/ibm/OPM
./OPMTstop.sh
10. Wait to complete the action and close the terminal window.

IBM Software
Figure 188 – OPMTstop.sh execution
• Close up all process and terminals. This is the end of the lab exercises.
LAB FILES:
cleanRange.db2 - Cleans all objects created in IO lab

checkTableIndexStats.db2 - Queries syscat.tables and syscat indexes for stats_time
createDB.db2 - drop recreate db2pt
createRSTATS_T1.db2 - Creates RSTAT schema and table
dftmonOff.db2 - Turn off system monitor switches
dftmonOn.db2 - Not used now, manual entry in lab
get_bphits_all.db2 - Get bp hit ratio with snapdb and MON_GET_BUFFERPOOL()
HighestReadTimePerContainer.db2 queries with MON_GET_CONTAINERS()
manual_cleanup_bpmontune.db2 - clean up bufferpool tablespace table if WE cleanup fails in we_run_BPMonTune.sh
Mon_Get_Workload_Details.db2 - Get lock wait statistics
reads_per_trx.db2 - queries reads per trx from snapdb
rread_per_rrtrnd.db2 - queries rows read per rows returned MON_GET_WORKLOAD()
setUpLockWait.db2 - Create table insert row for lock wait
showHoldingApp.db2 - Admin view snaplockwait
tbl_bpmontune - dummy data for tables
we_run_BPMonTune.sh - Start We scenario BPMonTune.sh
we_run_live_random.sh - Start WE scenario live_random (gui)
we_run_live_simple.sh - Start WE scenario live_simple (gui)
we_run_RangeNoSpread.sh - Start WE scenario RangeNoSpread.scn
we_run_RangeSpread.scn - Start WE scenario RangeSpread.scn
create_data.db2 – create data in the table documents

© Copyright IBM Corp. 2012. All rights reserved Page 100 of
102
IBM Software
12 Cleanup
If you want to cleanup your work you can use these commands.

db2 terminate
db2 drop db sample
db2stop

© Copyright IBM Corp. 2012. All rights reserved Page 101 of
102
IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.
IBM Software
DB2® Performance Tuning & Monitoring – SQL

Query Tuning
Hands-On Lab
IBM Software
Table of Contents
1 Objectives.............................................................................................................................................................................................3
2 Suggested reading ..............................................................................................................................................................................3
3 DB2 Design Advisor Lab .....................................................................................................................................................................3
3.1 Start DB2.............................................................................................................................................................................................................4
3.2 Create Database and Tables ..............................................................................................................................................................................5
3.3 Examine and Execute Workload .........................................................................................................................................................................6
3.4 DB2 Design Advisor ..........................................................................................................................................................................................17
3.5 Examine and Execute Workload after recommendations .................................................................................................................................19
4 Monitoring CPU and I/O Bound Queries..........................................................................................................................................20

4.1 Collect Activity metrics ......................................................................................................................................................................................20
4.2 Monitor I/O bound query ...................................................................................................................................................................................21
4.3 Monitor CPU bound query.................................................................................................................................................................................23
5 Administrative Views Lab .................................................................................................................................................................25

5.1 Monitor switches and start workload .................................................................................................................................................................25
5.2 Monitor database ..............................................................................................................................................................................................25
5.3 Execute workload..............................................................................................................................................................................................27
5.4 DB2 Design Advisor ..........................................................................................................................................................................................27
5.5 Execute workload after recommendations ........................................................................................................................................................27
6 Statement Concentrator Lab ............................................................................................................................................................28

6.1 Monitor switches ...............................................................................................................................................................................................28
6.2 No parameter markers test ...............................................................................................................................................................................28
6.3 With parameter markers test.............................................................................................................................................................................29
6.4 Rerun No parameter markers ...........................................................................................................................................................................30
7 Optim Query Workload Tuner Lab ...................................................................................................................................................31

7.1 Preparing the Database ....................................................................................................................................................................................31
7.2 Tune a Workload...............................................................................................................................................................................................33
7.2.1 Launching Data Studio......................................................................................................................................................................33
7.2.2 Create a Optim Query Tuner Project ................................................................................................................................................35
7.2.3 Run Workload Advisors ....................................................................................................................................................................39
7.3 Access Path Explorer and Access Graph .........................................................................................................................................................44
7.3.1 Run Single Query Advisors...............................................................................................................................................................49
7.4 Optimization Profiles .........................................................................................................................................................................................53
7.4.1 Create an Optimization Profile ..........................................................................................................................................................53
7.4.2 Create a New Join Sequence ...........................................................................................................................................................54
7.4.3 Set Access Path to IXSCAN .............................................................................................................................................................57
7.4.4 Validate Optimization Profile.............................................................................................................................................................58
7.4.5 Compare the Access Plan change....................................................................................................................................................58
7.4.6 Deploy Optimization Profile...............................................................................................................................................................59
8 SQL Performance Tuning – Clean Up..............................................................................................................................................61

IBM Software
1 Objectives
DB2 10 contains numerous SQL performance enhancements that continue to make the DB2 data server an industry - leading
data server solution that is suitable for any size of organization.
A number of performance improvements have been included in DB2 10 to improve the speed of many queries. These improve-
ments are automatic; there are no configuration settings or changes to the SQL statements required.
DB2 10 has up to 3x faster query performance than its predecessor, with new functionality and enhanced features like:
– Queries over star schemas
– Queries with joins and sorts
– Queries with aggregation
– Hash joins
In this lab, you will learn:
How to identify problematic SQL statements in your application
How to monitor SQL statement resource usage
How to view SQL query execution plans
Which database features help to improve the SQL statement performance
How to use the DB2 Design Advisor to gather SQL performance tuning recommendations
How to use the Optim™ Query Tuner graphic tool to obtained recommendation to improve performance based on a
workload
How to influence access plan selections to optimize query execution
2 Suggested reading
Best Practices: Tuning and Monitoring Database System Performance
http://www.ibm.com/developerworks/data/bestpractices/systemperformance/
Optim Query Tuner for DB2 product overview

Useful information for SQL based optimization
http://publib.boulder.ibm.com/infocenter/idm/v2r2/index.jsp?topic=%2Fcom.ibm.datatools.qrytune.nav.doc%2Ftopics%2Fhelpind
ex_qt.html
IBM Data Studio version 3.1 Information Center

http://publib.boulder.ibm.com/infocenter/dstudio/v3r1/index.jsp
3 DB2 Design Advisor Lab

In this part of the lab, you will work with the DB2 Design Advisor utility in DB2 10. You will run a workload on the database serv-
er and use the DB2 Design Advisor to decide what indexes or Materialized Query Tables (MQTs) are required to improve work-
load performance. After implementing the recommendations, the workload will be rerun. At the end of each run the workload
timings as well as the workload query access plans will be captured and compared.

IBM Software
3.1 Start DB2

You may skip this section if you have started your VM and db2 instance in a previous lab or exercise.
1. Login to the VMware virtual machine using the following information:
User: db2inst1
Password: password
2. Open a terminal window as by right-clicking on the Desktop area and choose the “Open Terminal” item.
3. Start up DB2 Server by typing “db2start” in the terminal window.

IBM Software
4. In order to enable the aliases defined for this lab and all labs that follow, copy the /home/db2inst1/labbashrc to
/home/db2inst1/.bashrc and source that file.
cd ~
. .bashrc
3.2 Create Database and Tables

We have provided you with a script, which creates a database and the tables that you will use in this portion of the lab.
The diagram of the database utilized for this exercise is shown below.
ad_whse database diagram

product_dim
prod_code char(6)
prod_name varchar(255)
prod_brand varchar(255)
prod_cat varchar (255) date_dim
day_day int
sales_fact day_of_week int
day_date date day_month int
prod_code char(6) day_month_name char(20)
store_num char(5) day_quarter char(2)
quantity integer day_quarter_name char(20)
day_year int
store_dim
store_num char(5)
state char(2)
country varchar(255)
Figure 2 – Database ad_whse diagram
1. While logged in as user “db2inst1”, change your working directory to the folder containing the work scripts.
qtdir
Or
cd ~/Documents/LabScripts/db2pt/querytuning
2. Before executing, take a look at the script, and note how the database, and tables are created.
cat crDbAndTabs.sql
3. Execute the script as follows:
db2 –tvf crDbAndTabs.sql

IBM Software
Note: Make sure that each SQL statement, except the first (database drop may fail because ad_whse had not been created yet), has
finished successfully. The following message should be returned after the successful completion of the SQL statement:
DB20000I The SQL command completed successfully.
4. With the database created run the following two scripts to populate the database tables and update the system catalogs
with the data statistics.
db2 –tvf load_data.sql

db2 –tvf run_stats.sql
Note: In DB2 10, a number of improvements have been made to the RUNSTATS command to make statistics gathering faster. One of
these improvements is that you no longer have to fully qualify object names by specifying a schema name. If you do not specify a schema
name, the default schema is used. You can view this displaying the file run_stats.sql
5. In this exercise the DB2 Design Advisor and the Visual Explain utility are used. These require the system Explain ta-
bles. Create the Explain tables by running the following commands:
Note that midir is a shortcut for directory ~/db2inst1 /sqllib/misc.
midir
db2 –tvf EXPLAIN.DDL
3.3 Examine and Execute Workload

With the environment setup, now examine the workload containing two problematic SQL statements.
1. Display the file batch_query.sql to view the two SQL statements. You may need to resize your terminal window to see
the first query.
qtdir
cat batch_query.sql
Leave this window open.
2. Open IBM Data Studio by double-clicking on the IBM Data Studio icon on the Desktop.
Figure 3 – Open IBM Data Studio
3. If this is the first time Data Studio is launched, it may take a moment. Click OK to accept the default workspace and
check the option “Use this as the default and do not ask again”.

IBM Software
Figure 4 – Select a workspace
4. By default, the Database Administration perspective is opened. Your workspace should look like the following:
Figure 5 – Database Administration perspective
5. We want to change to the IBM Query Tuning perspective. To do this, click on the “Open Perspective” icon and click
Other, as shown below.
Figure 6 – Open perspective

IBM Software
6. Click on IBM Query Tuning and click on the OK Button.
Figure 7 – Choose IBM Query Tuning perspective
Note: Perspective defines the initial set and layout of the components in your screen. Each perspective provides a set of functional-
ity aimed at accomplishing a specific type of tasks or works with specific types of resources.
7. In Data Source Explorer, expand the folder Database Connections until you see AD_WHSE.
Figure 8 – Choose AD_WHSE Database

IBM Software
8. Still in Data Source Explorer, right click AD_WHSE and select Connect.
9. In the pop-up dialog, fill in the connection details as follows and Click OK:
Database: AD_WHSE
Host: localhost
Port number: 50001
User name: db2inst1
Password: password
Figure 9 – Connection details window
10. After a connection has been successfully established, you should see this icon beside the AD_WHSE database in
the Data Source Explorer, which indicates a connected database. Disconnected databases are listed with . Expand-
ing the AD_WHSE database folder will list supported database object types, as seen in the following screen capture:

IBM Software
Figure 10 – Supported database object types
11. At the top menu bar in Data Studio, select File -> Open File, then open
/home/db2inst1/Documents/LabScripts/db2pt/querytuning/batch_query.sql, which is the file you just examined in Step
1 of this section.
12. You may need to specify the database connection against which the script is going to be executed. To do that, click on
“No Connection”, select AD_WHSE, and click Finish.

IBM Software
Figure 11 – Open batch_query.sql
13. Right click anywhere on the query and choose ‘Open Visual Explain’, click ‘Next’ to explore the options, then choose
“Finish” to generate the explain plan and diagram. You may want to double-click the tab
to maximize the view.
Note: In DB2 10, the Control Center and related components have been discontinued. These have been replaced by a new set of GUI
tools: IBM Data Studio and IBM InfoSphere Optim tools.
You’ll see the current query access plan that includes table scan operations. Drill down into the objects for additional de-
tails. The access plan is provided below for your reference. Notice the total cost is approximately 5,000 timerons.
Cost, in the context of access plans, is the estimated total resource usage necessary to execute the access plan for a
statement (or the elements of a statement).
Cost is derived from a combination of CPU cost (in number of instructions), I/O (in number of seeks and page transfers),
and communications cost.
The unit of cost is the timeron. A timeron does not directly equate to any actual elapsed time, but gives a rough relative es-
timate of the resources (cost) required by the database manager to execute different plans for the same query.
The cost shown in each operator node of an access plan graph is the cumulative cost, from the start of access plan execu-
tion up to and including the execution of that particular operator. It does not reflect other factors, such as the workload on
the system or the cost of returning rows of data to the user.

IBM Software
Figure 12 – Query Access Plan
Digging deeper into Statement 2, the join is on four tables, SALES_FACT, STORE_DIM, PRODUCT_DIM and
DATE_DIM. Table scans (TBSCAN) are being performed on each table. Three of these are dimension tables and are
small in size.
Right click on the ‘DB2INST1.STORE_DIM’ node and select ‘Show Description’. The Statistics time indicates when
the last time statistics were updated in the system catalog for the table you are viewing. Make sure the time is current.
Scroll through the statistics look for information like the Number of columns, the Number of rows, etc. The STORE_DIM
table has just 49 rows, making indexes unhelpful. You can do the same analysis on the other dimension tables too.

IBM Software
Figure 13 – DB2INST1.STORE_DIM Description
Right click the ‘DB2INST1.SALES_FACT’ node. Here you can look for ‘Number of rows’ and see that there are 707520
rows. You may think indexes will help, but look again. This warehouse statement has to read all the data in the table;
an index won’t help in this case either.

IBM Software
Figure 14 – DB2INST1.SALES_FACT Description
In this scenario, DB2 optimizer first performs a Hash Join between SALES_FACT and STORE_DIM tables on column
STORE_NUM.
Right click on the HSJOIN(8) node joining the SALES_FACT and DATE_DIM tables and select ‘Show description’.
The ‘Cumulative IO cost’ information is the estimated cumulative I/O cost (in data page I/Os) of executing the chosen
access plan up to and including this operator. The ‘Cumulative CPU Cost’ is the estimated cumulative CPU cost (in
instructions) of executing the chosen access plan up to and including this operator. The ‘Cumulative Total Cost’ is the
estimated cumulative cost (in timerons) of fetching the first row for the access plan up to and including this operator and
includes any initial overhead required.
The Cumulative properties section provides information on the tables in the join, the selected columns and the join
columns.

IBM Software
Figure 15 – HSJOIN Description
Hash join executes by requiring one or more predicates in the form table1.columnX = table2.columnY. In DB2 10, the
column types may be different.
First, the designated inner table, DATE_DIM is scanned and rows are copied into memory buffers that are drawn from
the sort heap. The memory buffers are divided into sections, based on a hash value that is computed on the columns of
the join predicates. If the size of the inner table exceeds the available sort heap space, buffers from selected sections
are written to temporary tables.
When the inner table has been processed, the second (or outer) table, SALES_FACT is scanned and its rows are
matched with rows from the inner table by first comparing the hash value that was computed for the columns of the join
predicates. If the hash value for the outer row column matches the hash value for the inner row column, the actual join
predicate column values are compared.
Outer table rows that correspond to portions of the table that are not written to a temporary table are matched
immediately with inner table rows in memory. If the corresponding portion of the inner table was written to a temporary
table, the outer row is also written to a temporary table. Finally, matching pairs of table portions from temporary tables
are read, the hash values of their rows are matched, and the join predicates are checked.
Note: Default value is subject to change by the DB2 Configuration Advisor after initial database creation.
For the full performance benefit of hash joins, the value of the sortheap database configuration parameter and the
sheapthres database manager configuration parameter may have to be changed. Alternatively, you can configure
sort heaps to be controlled by STMM by setting the sheapthres to 0 and the sortheap to automatic.

IBM Software
Note: sheapthres default value is subject to change by Configuration Advisor after initial database creation.
Hash join performance is best if you can avoid hash loops and overflow to disk. To tune hash join performance,
estimate the maximum amount of memory that is available for sheapthres and then tune the sortheap parameter.
Increase its setting until you avoid as many hash loops and disk overflows as possible, but do not reach the limit that is
specified by the sheapthres parameter.
You can monitor the TOTAL_HASH_JOINS, POST_SRTHRESHOLD_HASH_JOINS, TOTAL_HASH_LOOPS,

HASH_JOIN_OVERFLOWS and HASH_JOIN_SMALL_OVERFLOWS elements using the SNAPAPPL administrative
view.
DB2 introduces new columns to SNAPAPPL Administrative view like DBPARTITIONNUM, TOTAL_OLAP_FUNCS,
OLAP_FUNC_OVERFLOWS and MEMBER. Consult SNAPAPPL administrative view and SNAP_GET_APPL table
function section from DB 10 Information Center for details.
Use the db2batch utility to find out how long it takes to execute this workload. The db2batch tool can read SQL
statements from either a flat file or from standard input, dynamically prepare and execute the statements, and return a
result set. It also enables you to control the number of rows that are returned to db2batch and the number of rows that
are displayed. You can specify the level of performance-related information that is returned, including elapsed time,
processor time, buffer pool usage, locking, and other statistics collected from the database monitor. If you are timing a
set of SQL statements, db2batch also summarizes the performance results and provides both arithmetic and
geometric means.
DB2 10 introduces Command parameter WFO which specifies that the db2batch operation should wait for the
outcome of an operation. For Cursor Stability and higher scans, db2batch will wait for the commit or rollback when
encountering data in the process of being updated or deleted. Rows in the process of being inserted are not skipped.
14. Run the following command in the terminal window:
db2batch -d ad_whse -f batch_query.sql -r result.out,summary.out -v on –g

off
Note: There is no space between result.out and summary.out.
This command will run the two workload statements 25 times and capture the results in the files result.out and timings
in the file summary.out.
15. View the contents of the .out files by running the commands:
cat summary.out
cat result.out

IBM Software
The contents of the summary.out file are provided below. Consider this result can be a little different.
* Summary Table:
Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Arithmetic Mean
Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- ---------------
-------------- -------------- -------------
Statement 1 25 19.777257 0.382162 1.551512 0.791090
0.756770 4 4
Statement 2 25 49.666674 1.087114 3.072242 1.986667
1.905023 132 132
* Total Entries: 2
* Total Time: 69.443931 seconds
* Minimum Time: 19.777257 seconds
* Maximum Time: 49.666674 seconds
* Arithmetic Mean Time: 34.721965 seconds
* Geometric Mean Time: 31.341196 seconds
In this scenario it took about 49 seconds to execute statement 2 and about 69 seconds to execute the workload. The perform-
ance of this workload can be improved. In the next section, we’ll show you how by be using the DB2 Design Advisor. You can
leave all windows and applications open, as we’ll use them in the next section.
3.4 DB2 Design Advisor

DB2 Design Advisor identifies all of the objects that are needed to improve the performance of your workload. When the DB2
Design Advisor analyzes a specific workload, it considers many factors, such as the type of statements in the workload, the fre-
quency a particular statement occurs, and the characteristics of your database, to generate recommendations that minimize the
total cost of running the workload.
Given a set of SQL statements in a workload, the Design Advisor will generate recommendations for:
• New indexes
• New clustering indexes
• New Materialized Query Tables (MQTs)
• Conversion to multidimensional clustering (MDC) tables
• The redistribution of tables in a partitioned database
Note: The wizard interface for the design advisor is discontinued in DB2 10, but the design advisor is still available using the
db2advis command.
1. To gather the recommendations of the DB2 Design Advisor, run the following command:
db2advis -d ad_whse -i batch_query.sql -l -1 -m IMCP –o advise.out
Note: The first –l is a lowercase L; second -1 is a negative one.

IBM Software
In this workload the first statement will be run 250 times and the second statement will run 200 times. The statements
are available in the file batch_query.sql.
The recommendations of the DB2 Design Advisor are captured in the file advise.out.
Note: Since the Query Patroller is no longer supported in Version 10, the –qp option parameter for the db2advis command has been
discontinued.
2. To view the recommendations run:
cat advise.out
For our test workload, the DB2 Design Advisor provided the following recommendations. Typically you would want to
edit this file and change the system generated names to something more meaningful.
-- LIST OF RECOMMENDED INDEXES

-- ===========================
-- index[1], 0.021MB
CREATE INDEX "DB2INST1"."IDX1203232129310" ON "DB2INST1"."DATE_DIM"
("DAY_DATE" ASC, "DAY_QUARTER_NAME" ASC) ALLOW REVERSE
SCANS COLLECT SAMPLED DETAILED STATISTICS;
COMMIT WORK ;
-- index[2], 0.013MB
CREATE INDEX "DB2INST1"."IDX1203232128250" ON "DB2INST1"."DATE_DIM"
("DAY_YEAR" ASC, "DAY_DATE" ASC) ALLOW REVERSE SCANS COLLECT SAMPLED DETAILED STATISTICS;
COMMIT WORK ;
-- index[3], 0.013MB
CREATE INDEX "DB2INST1"."IDX1203232129060" ON "DB2INST1"."PRODUCT_DIM"
("PROD_CAT" ASC, "PROD_BRAND" ASC, "PROD_CODE" ASC)
ALLOW REVERSE SCANS COLLECT SAMPLED DETAILED STATISTICS;
COMMIT WORK ;
Note: Index Management re-defined in DB2 10:

• Jump Scan
o Need fewer indexes
• Smart Index Pre-fetching
o Faster index access & fewer index reorgs
• Smart Data Pre-fetching
o Faster index scans & fewer index reorgs
• Predicate Evaluation Avoidance
o Faster index scans
3. To implement the recommendations run the following commands:
db2 connect to ad_whse

db2 –tvf advise.out

IBM Software
3.5 Examine and Execute Workload after recommendations

Now that the recommendations have been implemented, we should check if they improved workload performance. This is done
by generating the query access plans and running the workload again. Visual Explain will be used for this purpose.
1. You should still have batch_query.sql open in the editor inside your Data Studio workspace. Right click anywhere
within the SQL editor, select Open Visual Explain, keep all default values, click Finish to view the updated access plan
graph. Maximize the Access Plan Diagram view if you want.
2. The access plan for the second SQL statement is provided below for your reference. In the example, the query execu-
tion cost has changed and now the execution of the query has been improved.
Figure 16 – New Access Plan

3. To re-determine the time it takes to execute this workload run the following command from the command window:
db2batch -d ad_whse -f batch_query.sql -r result_new.out,summary_new.out –v

on –g off
This will run the two workload statements 25 times and capture the results in a result_new.out and timings in sum-
mary_new.out file.
4. To compare the old and new timings, display the .out files:
cat summary.out
cat summary_new.out
Sample contents of the summary_new.out file are provided below, actual numbers may vary.

IBM Software
* Summary Table:
Type Number Repetitions Total Time (s) Min Time (s) Max Time (s) Arithmetic Mean
Geometric Mean Row(s) Fetched Row(s) Output
--------- ----------- ----------- -------------- -------------- -------------- ---------------
-------------- -------------- -------------
Statement 1 25 14.132961 0.389929 0.804882 0.565318
0.553693 4 4
Stat 2 25 35.373943 0.885524 2.556759 1.414958
1.362658 132 132
* Total Entries: 2
* Total Time: 49.506904 seconds
* Minimum Time: 14.132961 seconds
* Maximum Time: 35.373943 seconds
* Arithmetic Mean Time: 24.753452 seconds
* Geometric Mean Time: 22.359306 seconds
As you can see the first statement did not benefit from the MQT or the indexes. But the second statement execution time has
substantially reduced due to the MQT. The net result is that the total workload time has been reduced due to the DB2 Design
Advisor recommendations.
You can close the IBM Data Studio but leave the command window open for the next set of exercises.
4 Monitoring CPU and I/O Bound Queries

DB2 10 provides relational monitoring interfaces that are more efficient and have a lower impact on the system than previous
system monitor and snapshot interfaces. These interfaces can be accessed directly by SQL and provide enhanced reporting
and monitoring of the database system, data objects, and the package cache to help you quickly identify issues that might be
causing problems.
In this lab, we’ll use the MON_GET_PKG_CACHE_STMT table function interface to identify the problematic SQL statements.
MON_GET_PKG_CACHE_STMT reports information for both static and dynamic SQL statements, unlike the dynamic SQL
snapshot which only reports information for dynamic statements. We’ll use the DB2 Design Advisor to suggest indexes to
increase the performance of these SQL statements. These will be applied followed by an execution time comparison.
4.1 Collect Activity metrics
First you will execute a DB2 script file to create the new event monitor for locking. Open up a terminal window and change your
current directory to '/home/db2inst1/Documents/LabScripts/db2pt/querytuning':
Note: In DB2 10 new event monitors features exist:

• All event monitors now support the WRITE TO TABLE target
• Existing event monitors that write to tables can be altered to capture additional logical data groups

IBM Software
1. Restart the database and check if the database configuration parameter mon_act_metrics which provides metrics
about activities being performed on the database is turned on. It is on by default, with a setting of BASE. To confirm
execute:
db2stop force
db2start
qtdir
db2 get db cfg | grep –i mon
Note: Make sure that MON_ACT_METRICS=BASE. On databases created prior to V9.7 and then upgraded to V9.7 or higher, the
mon_act_metrics parameter is set to NONE by default. In version 10 the BASE setting of MON_ACT_METRICS includes metrics re-
ported through MON_GET_PKG_CACHE_STMT and MON_GET_PKG_CACHE_STMT_DETAILS .
2. View Bad query SQL statement with the following command:
cat badquery.sql
4.2 Monitor I/O bound query

1. Use the db2batch utility to execute the bad query statement by issuing the following command:
db2batch –d ad_whse –f badquery.sql –r beforeresults.out,beforesummary.out

This will run the bad query and capture the results in a beforeresult.out and timings in beforesummary.out.
View the SQL statement execution timings by running.
cat beforesummary.out
2. Let’s investigate by collecting the top ten dynamic & static SQL statements ordered by the average CPU time by using
the MON_GET_PKG_CACHE_STMT table function. It returns a point-in-time view of SQL statements in the database
package cache. This allows us to examine the aggregated metrics for a particular SQL statement, allowing us to quickly
determine the reasons for poor query performance.
Note: In DB2 10, MON_GET_PKG_CACHE_STMT returns additional columns that report metrics about I/O server efficiency, processing
time for authentication, statistics generation, statement execution, high water mark input values, and extended latch waits.
It also allows us to compare the behavior of an individual cached section, relative to the other statements, to assist in
identifying the most expensive section or statements.
db2 –td! -vf mon.sql

We can see that from the output that the bad query spent most of its activity time in a waiting state. The TO-
TAL_ACT_WAIT_TIME is approximately eighty percent of the TOTAL_ACT_TIME. We can also see that The
LOG_DISK_WAIT, LOCK_WAIT and query PREP_TIME are almost negligible. This gives us a hint that this query
maybe I/O bound. We can also see that the ROWS_READ to ROWS_RETURNED ratio is high. This tells us that this
query is not optimized and is missing an index. The operating system monitoring tools like iostat can also show if the
database workload is I/O bound.

IBM Software
STATEMENT AVG_CPU_TIME TOTAL_ACT_TIME TOTAL_ACT_WAIT_TIME

LOCK_WAIT_TIME LOG_DISK_WAIT_TIME PREP_TIME ROWS_READ ROWS_RETURNED
----------------------------------------------------------------------------------------------------------------
select b.prod_name, b.prod_brand from sales_fact a 166736 797 725
0 0 66 707575 85913
SQL0445W Value "select b.prod_name, b.prod_brand from sales_fact a, product_d" has been truncated.SQLSTATE=01004
SELECT varchar(container_name, 70) as container_nam 120908 122 0

0 0 79 0 4
SELECT CURRENT QUERY OPTIMIZATION FROM SYSIBM.SYSD 89 0 0
0 0 61 0 1
select current CLIENT_APPLNAME, current CLIENT_ACC 28 0 0
0 0 1 0 1
4 record(s) selected with 1 warning messages printed.
3. Let’s look at the query plan of this bad query to confirm that it maybe missing an index. You will use DB2 Explain to do
so. Run this command to get the query plan:
db2expln –d ad_whse –f badquery.txt –g –t
Operator
(ID)
RETURN
( 1)
|
HSJOIN
( 2)
/----/ \-----\
TBSCAN FETCH
( 3) ( 4)
| /--/ \
Table: IXSCAN Table:
DB2INST1 ( 5) DB2INST1
SALES_FACT | PRODUCT_DIM
Index:
DB2INST1
IDX1203262340360
We can see that the query is doing a table scan on the table SALES_FACT which has 707520 rows. An index on this
table should improve performance by reducing the I/O.
4. Now let us use the DB2 Design Advisor to get recommendations to improve this query.
db2advis –d ad_whse –i badquery.sql –o indexrec.sql

-- ===========================
-- index[1], 3.927MB
CREATE INDEX "DB2INST1"."IDX1203232156340" ON "DB2INST1"."SALES_FACT"

IBM Software
("QUANTITY" ASC, "PROD_CODE" DESC) ALLOW REVERSE SCANS COLLECT SAMPLED DETAILED STATISTICS;
COMMIT WORK ;
5. Let us create the recommended index for this query and run the statistics.
db2 –tvf indexrec.sql

db2 –tvf run_stats.sql
6. Let us now see the query plan of this bad query to confirm that it has improved by using this new index. Run this com-
mand to get the query plan.
db2expln –d ad_whse –f badquery.txt –g –t
We can see the plan has improved by doing an Index scan instead of a table scan and the estimated cost of the query
is lower.
Operator
(ID)
RETURN
( 1)
|
HSJOIN
( 2)
/------/ \------\
IXSCAN FETCH
( 3) ( 4)
| /--/ \
Index: IXSCAN Table:
DB2INST1 ( 5) DB2INST1
IDX1203270014270 | PRODUCT_DIM
Index:
DB2INST1
IDX1203262340360
4.3 Monitor CPU bound query

We will now run a bad query which is CPU intensive.
1. We need to create a test table for this exercise. This command will create a table with more than a million rows.
db2 -td! –vf initscript.sql

2. View and execute the bad query2 statement using the db2batch utility.
cat badquery2.sql
db2batch –d ad_whse –f badquery2.sql –r oldresults.out,oldsummary.out
This will run the bad query2 and capture the results in oldresult.out and timings in oldsummary.out.

IBM Software
3. View the SQL statement execution timings by running.
cat oldsummary.out
4. Let us again get the top ten dynamic & static SQL statements ordered by the average CPU time using the
MON_GET_PKG_CACHE_STMT table function. It returns a point-in-time view of SQL statements in the database
package cache. This allows us to examine the aggregated metrics for a particular SQL statement, allowing us to quickly
determine the reasons for poor query performance.
db2 –td! -vf mon.sql

We can see that from the output of this interface that this bad query spent most of the time doing CPU processing and
very little wait time. The TOTAL_ACT_WAIT_TIME is pretty low. We can also see that the LOG_DISK_WAIT,
LOCK_WAIT are almost negligible. This gives us a hint that this query maybe CPU bound. We can also see that the
ROWS_READ to ROWS_RETURNED ratio is high. This tells us that this query is not optimized and is missing an index. This
is causing the query to process more rows in memory making it CPU intensive.
5. Let us now see the query plan of this bad query2 to confirm that it may be missing an index. Run this command to get
the query plan.
db2expln –d ad_whse –f badquery2.txt –g –t

We can see that the query is doing a table scan on the table MANYROWS. An index on this table will improve perform-
ance by reducing the number of rows accessed.
6. Now let us use the design advisor to provide recommendations to improve this query.
db2advis –d ad_whse –i badquery2.sql –l -1 –o indexrec2.sql
Note: The first –l is a lowercase L; the second -1 is a negative one.

-- ===========================
-- index[1], 23.040MB
CREATE INDEX "DB2INST1"."IDX909250528440000" ON "DB2INST1"."MANYROWS"
("COL1" ASC, "COL2" DESC) ALLOW REVERSE SCANS COLLECT SAMPLED DETAILED STATISTICS;
COMMIT WORK
7. Let us create the recommended index for this query and run the statistics.
db2 –tvf indexrec2.sql

db2 runstats on table db2inst1.manyrows
8. Let us now see the query plan of this bad query2 to confirm that it has improved by using this new index. Run this
command to get the query plan:
db2expln –d ad_whse –f badquery2.txt –g –t

We can see the plan has improved by doing an index scan instead of a table scan and the estimated cost of the query
is much lower.

IBM Software
9. Execute the bad query2 statement again using the db2batch utility.
db2batch –d ad_whse –f badquery2.sql –r newresults.out,newsummary.out

This will run the bad query2 and capture the results in a newresults.out and timings in newsummary.out.
10. Compare the OLD and NEW execution times and observe the improvement in query performance.
cat oldsummary.out
cat newsummary.out
5 Administrative Views Lab

Using the database ‘ad_whse’, we’ll run administrative views to monitor the SQL statements currently running on the database
server, capture the longest running SQL statements, and check the buffer pool hit ratio. After identifying the problematic SQL
statements we’ll use the DB2 Design Advisor to suggest indexes, MQTs or MDCs to increase the performance of these SQL
statements. These will be applied followed by an execution time comparison.
5.1 Monitor switches and start workload

1. As you’ll be monitoring the database server resource usage, turn on the system monitor switches. For these settings to
take effect restart the database server as well. Do this by running the script:
qtdir
mon_switch_on
2. The workload for this exercise consists of five SQL statements that are continuously run against the database server.
To start the workload, in the terminal windows type the following commands:
start_batch
3. To examine the five SQL statements type the following command:
less all_query.sql
5.2 Monitor database

1. With the workload running in the background, connect to the database and monitor the database server activity. Use
the following administrative views for this purpose.

2. To list all the dynamic & static SQL statements ordered by the average CPU time you could use the
MON_GET_PKG_CACHE_STMT table function, as we have in previous exercises. However, by enabling both frameworks
you will incur overhead from both monitoring frameworks, so careful consideration is required. As an alternative you will

IBM Software
use the SYSIBMADM.SNAPDYN_SQL administrative view and SNAP_GET_DYN_SQL table function, which are available
in all supported versions of DB2, to return the top 5 dynamic SQL statements with regards to total CPU consumption.
db2 –tvf snapdyn_sql.sql

Note: In version 10, SNAP_GET_DYN_SQL_V95 table function has been deprecated and replaced by the SNAP_GET_DYN_SQL
3. To display a list of statements with information about the time required to prepare the statement, we use the QUE-
RY_PREP_COST administrative view. When selecting from the view, an order by clause can be used to identify queries
with the highest prep cost. We can examine this view to see how frequently a query is run as well as the average exe-
cution time for each of these queries. If the time it takes to compile and optimize a query is almost as long as it takes for
the query to execute, you might want to change the optimization class that you are using. Lowering the optimization
class might make the query complete optimization more rapidly, returning a result sooner. However, if a query takes a
significant amount of time to prepare but is executed thousands of times (without being prepared again) then the opti-
mization class might not be an issue.
db2 –tvf prep_cost.sql

4. To list the top dynamic SQL statements sorted by number of executions, average execution time, number of sorts, or
sorts per statement, you use the TOP_DYNAMIC_SQL administrative view. These are the queries that represent some of
the biggest resource consumers and should be analyzed to ensure they are well tuned.
db2 –tvf top_dyn.sql

5. The LONG_RUNNING_SQL administrative view returns the longest running SQL statements in the currently connected
database and the current status of the query. Using agent ID as the unique identifier, you can investigate the applica-
tion containing the SQL statement. If executing a long time and waiting on a lock, you might want to dig deeper using
the LOCKWAITS or LOCKS_HELD administrative views. If “waiting on User”, this means that the database server is not
doing anything and waiting for the application (like issue the next fetch or submit the next SQL statement).
db2 –tvf long_run.sql

6. The BP_HITRATIO administrative view returns bufferpool hit ratios, including total hit ratio, data hit ratio, XDA hit ratio
and index hit ratio, for all bufferpools and all database partitions in the currently connected database. The ratio of phys-
ical reads to logical reads gives the hit ratio for the bufferpool. The lower the hit ratio, the more the data is being read
from disk rather than the cached buffer pool which can be a more costly operation.
db2 –tvf buf_hit.sql

Once you’ve identified the slow performing SQL statements use the DB2 Design Advisor for recommendations on im-
proving the workload performance.
7. First stop the workload by shutting down the database server. This will throw some error messages that can be safely
ignored. Run.
db2stop force
8. Restart the database server for the next step.
db2start

IBM Software
Note: in Version 10, some system catalog views and administrative SQL routines changed to include the database member infor-
mation.
5.3 Execute workload

1. Capture the workload current execution timings by running the workload using the following command:
db2batch -d ad_whse -f all_query.sql -r result_OLD.out,summary_OLD.out

2. View the workload current execution timings by running
cat summary_OLD.out
5.4 DB2 Design Advisor

1. Now invoke the DB2 Design Advisor for this workload using the command:
db2advis -d ad_whse -i all_query.sql -l -1 -m IMCP -o all_advise.out
Note: The first –l is a lowercase L; the second -1 is a negative one.
2. The recommendations of the DB2 Design Advisor are captured in the file all_advise.out. View the recommendations us-
ing:
cat all_advise.out
3. As part of the recommendations new MQTs have been recommended and the earlier one will be reused. Implement the
recommendations by running:

db2 –tvf all_advise.out
5.5 Execute workload after recommendations

1. With the recommendations in place, rerun the workload and capture the new execution timings. Run the command:
db2batch -d ad_whse -f all_query.sql -r result_NEW.out,summary_NEW.out
2. Display the old and new timings by running:
cat summary_OLD.out
cat summary_NEW.out
Compare the old and new execution times and observe the improvement in query performance.

IBM Software
6 Statement Concentrator Lab

The statement concentrator modifies dynamic SQL statements at the database server so that similar, but not identical, SQL
statements can share the same access plan.
For SQL statements that need to be executed many times, where the only difference in the statement are the variables used as
predicates, it is often beneficial to prepare the SQL statement once and reuse the query plan by using parameter markers to
substitute the predicate values during runtime.
In this exercise you will first run two workloads, both will create 10 connections, each inserting a row into a single predefined
table. The process will repeat 10,000 times inserting a total 100,000 rows into the table. The difference between the workloads
is that one utilizes parameter markers and the other does not. Then, you will again run the workload that does not use
parameter markers, but this time with the new statement concentrator variable turned on. At the end of each run, a snapshot of
the database will be taken to compare relative Host Execution Elapsed Time and other counters.
6.1 Monitor switches

1. As you’ll be monitoring the database server resource usage, turn on the system monitor switches. For these settings to
take effect you’ll restart the database server as well. Do this by running the script:
qtdir
./mon_switch_on
6.2 No parameter markers test

1. Initialize the run by activating the database. Then you will check the “host execution elapsed time” with a database
snapshot, it should be zero (or close to) since no application code has been executed against the database.

db2 get snapshot for database on ad_whse | grep Host
Host execution elapsed time = 0.000000
2. Enter the alias to take you to the workload expert working directory, and then run the noPmarkers.scn file to have the
application insert 100,000 rows into the predefined table.
we –r –scn ~/Documents/LabScripts/db2pt/querytuning/noPmarkers.scn –db

localhost:50001/ad_whse –u db2inst1 –p password
This will take a couple of minutes to run, wait until it completes.
Look for “All schedules completed. (no error)”

IBM Software
Figure 17 – “we” execution output
Note the Host execution elapsed time here _______________
6.3 With parameter markers test

1. You will need to restart the instance and activate database to reset counters and help ensure a run consistent with the
first one:
db2 terminate
db2stop force
db2start
db2 activate database ad_whse
(Should be 0.00 or very low number).

2. Run the workload that utilizes parameter markers and record execution time.
we –r –scn ~/Documents/LabScripts/db2pt/querytuning/yesPmarkers.scn –db


IBM Software
6.4 Rerun No parameter markers

1. This time you will rerun the “no parameter markers” scenario but first you will update the database configuration so that
the statement concentrator is on and restart the instance as in previous runs.
db2 update db cfg for ad_whse using stmt_conc literals

db2 terminate
db2stop force
db2start
db2 activate database ad_whse
(Should be 0.00 or very low number).
2. Rerun the “no parameter markers” scenario and record results.
we –r –scn ~/Documents/LabScripts/db2pt/querytuning/noPmarkers.scn –db


Compare your results, you should find that by using parameter markers or the statement concentrator you can reduce the time it
takes to process SQL statements.

IBM Software
7 Optim Query Workload Tuner Lab

In this part of the lab, you will work with the Optim Query Tuner graphical tool with DB2 10. You will run a workload on the data-
base server and use advisors to obtained recommendations indexes, statistics and views are suggested to improve the work-
load performance. The recommendations received will be applied to the database server and the workload rerun.
7.1 Preparing the Database

1. Open a new terminal window by right-clicking on the Desktop and choosing the “Open Terminal” item:
2. Use the terminal window directory to prepare the database with script oqwt01.sh located in /home/db2inst1/Documents
/LabScripts/db2pt/querytuning/oqwt. Run the following command:
oqwtdir
./oqwt01.sh
After some time, the following should display, indicating that everything has been processed successfully:

IBM Software
-----------------------------------------------------------------------------
Run EXPLAIN.DDL in the SAMPLE database
-----------------------------------------------------------------------------
Database Connection Information
Database server = DB2/LINUXX8664 10.1.0

SQL authorization ID = DB2INST1
Local database alias = SAMPLE

-----------------------------------------------------------------------------
Applying OQWT License to the SAMPLE database
-----------------------------------------------------------------------------
Database server = DB2/LINUXX8664 10.1.0

Local database alias = SAMPLE
DROP FUNCTION DB2OE.QT_LIC

CREATE FUNCTION DB2OE.QT_LIC() RETURNS VARCHAR(255) LANGUAGE SQL CONTAINS SQL NO EXTERNAL ACTION
DETERMINISTIC RETURN VARCHAR('wVLwF/a4OBBLTyNX4bsUKw==')
GRANT EXECUTE ON FUNCTION DB2OE.QT_LIC TO PUBLIC WITH GRANT OPTION


-----------------------------------------------------------------------------
Note: You have applied OQWT license to the SAMPLE database

IBM Software
7.2 Tune a Workload

7.2.1 Launching Data Studio
1. Open IBM Data Studio by double-clicking on the IBM Data Studio icon on the Desktop.
Figure 19 – Open IBM Data Studio
2. If this is the first time Data Studio is launched, it may take a moment. Click OK to accept the default workspace and
check the option “Use this as the default and do not ask again”.
Figure 20 – Select a workspace

3. By default, the Database Administration perspective is opened. Your workspace should look like the following:

IBM Software
Figure 21 – Database Administration perspective
4. We want to change to the IBM Query Tuning perspective. To do this, click on the “Open Perspective” icon and click
Other, as shown below.
Figure 22 – Open perspective

IBM Software
Click on IBM Query Tuning and click on the OK Button.
Figure 23 – IBM Query Tuning Perspective
7.2.2 Create a Optim Query Tuner Project
1. Move your mouse pointer to the Project Explorer section, right-click and select New, and then Project…
Figure 24 – Create New Project

IBM Software
2. Select Query Tuner Project from the wizard list and click Next.
Figure 25 – Query Tuner Project Wizard
3. Leave the Project Name as suggested in the wizard and click Next.
Figure 26 – Query Tuner Project Name

IBM Software
4. Select the SAMPLE database for the connection and click Next. If necessary create connection following steps 6 to 8
in Lab 3.3 of this workbook. Remember use SAMPLE as database name. Then click Finish.
Figure 27 – Select Database connection
5. In this lab, we will use a workload file, with multiple SQL statements. First select File and click Browse.
Figure 28 – Capture SQL Sentences
6. Select the file OQWT.sql located in /home/db2inst1/Documents/LabScripts/db2pt/querytunning/oqwt, and

click OK.

IBM Software
Figure 29 – Select query workload file
7. Use “;” as statement delimiter, click Capture and, click Capture. Once the statement appears on screen, click Save
All to Workload…
Figure 30 – Capture workload
8. Accept the default workload name and click OK.

IBM Software
Figure 31 – Workload Name
7.2.3 Run Workload Advisors

1. Click Invoke Advisors to call workload advisors and tools.
Figure 32 – Invoke Advisors
2. Check Re-collect EXPLAIN information before running workload advisors. Click Select What To Run…. Click
Select All, and click OK.

IBM Software
Figure 33 – Select categories for recommendation
3. Specify the TPCDS schema and click Start EXPLAIN.
Figure 34 – Specify Explain Values
4. There may be Unexplained Statements such as “set current schema= ‘TPCDS’”, Click Yes to continue.

IBM Software
Figure 35 – Status
5. Workload advisors will start working on the workload. Please wait for this to finish.
Figure 36 – Running advisors
6. In case if an error window is displayed, press OK.
7. After this, the recommendations are presented. We’ll review them in the next few steps.
Figure 37 – Recommendation Summary
8. Click the Statistics tab and click View RUNSTATS.

IBM Software
Figure 38 – Statistics Tab
9. Review the recommendations, in particular Merged RUNSTATS. Click Next.
Figure 39 – Statistics Recommendations
10. Click Finish to execute the RUNSTATS COMMANDS on the database. Click OK in the confirmation window.

IBM Software
Figure 40 – RUNSTATS Commands
Note: In DB2 10, a number of improvements have been made to the RUNSTATS command to make statistics gathering faster. The
command parameters have also been simplified.
11. Click the Indexes tab to explore recommendations for indexes.
Figure 41 – Indexes Recommendations

12. Click Statistical Views tab to see the recommendations. The use of statistical view helps to improve the
performance of queries and OQWT helps to determine these views based upon the workload. It is not an easy task
to do by hand.

IBM Software
Figure 42 – Statistical Views Recommendations
13. Close project tab as shown, Save changes and Exit.
Figure 43 – Close Project Tab
7.3 Access Path Explorer and Access Graph
1. Open a new terminal window by right-clicking on the Desktop and choosing “Open in Terminal.”:

IBM Software
2. Run the oqwt03.sh script located in directory /home/db2inst1/Documents/LabScripts/db2pt/querytuning/oqwt to cre-

ate two tables, wait for a message stating that it “Successfully Executed”.
oqwtdir
./oqwt03.sh
3. Back in Data Studio, right-click on the QTProject1 and select Create Query Group. [We saved this project in the
previous section.]
Figure 45 – Create Query Group
4. Accept the default name and click OK.

IBM Software
Figure 46 – Default Query Group name
5. Right click on Query Group X, where X is the generated group number, and select the option Tune Query.
Figure 47 – Tune Query

IBM Software
6. As in the previous section we need a file with a SQL statement to optimize Click File, and then click Browse.
Figure 48 – Select file with SQL

IBM Software
7. Select the file OQWT04.sql located in /home/db2inst1/Documents/LabScripts/db2pt/querytunning/oqwt.

Click OK, use “;” as statement delimiter and click Capture. Once the statement appears on screen, click Save All
to Workload…
Figure 49 – Capture SQL from a File

IBM Software
8. Select workload name you just saved in the previous step, double click to open.
Figure 50 – Manage Workload
7.3.1 Run Single Query Advisors

1. Click the vertical tab “2. Capture” so that we can run advisors. Click Invoke Advisors and Tools.
2. Click Select What To Run…

IBM Software
3. Click Select All, then OK.
Figure 53 – Select Activities

IBM Software
4. The single query tune advisor will start to run. Please wait for this to finish.
Figure 54 –Tuning Query
5. Click Open Access Plan Explorer.
Figure 55 – Access Plan Tabular View

IBM Software
6. Click Open Access Plan Graph.
Figure 56 – Access Plan Graph View

IBM Software
7. Notice in the access plan graph, there is a HASH JOIN between a full table scan on the table OQWT_T2 and
IXSCAN on the table OQWT_T1. We will take this as an example and show you how to create an optimization
profile to influence the query access path.
Figure 57 – Access Plan Graph Detail
7.4 Optimization Profiles

An optimization profile is a DB2 feature that allows a DBA to provide a “hint” for an SQL statement. Normally, the DB2 optimizer
does not require “hints”, but it may be necessary to influence the optimizer to do things in a particular fashion ONLY for a
particular query.
To set up the optimization profile, we will use the access plan graph of the query we saw in the previous section.
We will create an optimization profile using the following requirements.
1. OQWT_T1 table to be accessed with IXSCAN and it should use index OQWT_T1_IX1
2. OQWT_T2 must be a leading table in the join sequence and the join method for OQWT_T1 must be nested-loop join
and not the hash-join shown in the access plan graph
7.4.1 Create an Optimization Profile

1. Click vertical tab “4. Invoke.” Click Create Optimization Profile.

IBM Software
Figure 58 – Create Optimization Profile
2. Please notice that the Plan-Hint 1 is created. You will see two panes on the right-hand side. One of them is the Join
Diagram, based on existing access plan. The other is the Editable Join Sequence Diagram. We will work from the
second graph window.
Figure 59 – Create Plan Hint
7.4.2 Create a New Join Sequence

1. Right-click anywhere in the Editable Join Sequence Diagram. Select Add Join as Child node.

IBM Software
Figure 60 – Adding Join
2. Click the Join Type dropdown, select NLJOIN and click OK.
Figure 61 – Join Type
3. An NLJOIN box is created in the diagram window. Click to select it. Right-click and select Add table reference as a
child node.

IBM Software
Figure 62 – Add table reference
4. Select Q2 (OQWT_T1) and click OK.
Figure 63 – Select Right Table Reference
5. Right-click on the NLJOIN box. Select Add table reference as a child node.
Figure 64 – Add Table Reference
6. Click Q1 line (OQWT_T2). Click OK in the dialog box.

IBM Software
Figure 65 – Select left Table Reference
7.4.3 Set Access Path to IXSCAN

1. You will notice the nested loop join sequence created between two tables as shown. Double click the OQWT_T1
box.
Figure 66 – Join Sequence Diagram
2. Click the Value in Guideline dropdown. Select IXSCAN and click Select Index. Check DB2INST1.OQWT_T1_IX1
and click OK.
Figure 67 – Select access type and Index

IBM Software
Figure 68 – Select DB2INST1.OQWT_T1_IX1Index
3. You will notice the following join graph between two tables.
Figure 69 – Join Graph
7.4.4 Validate Optimization Profile

1. Click the Validate Optimization Profile icon, which is the left one and accept all default values. Click Validate.
Please wait for the validation process to complete.
Figure 70 – Validate Optimization profile

.
7.4.5 Compare the Access Plan change
1. After validation, a new window opens with the validation results. Scroll all the way down. Notice that there are no
errors or warnings.
2. Click the link (at the bottom of the window) to compare the new access path after applying the optimization profile.

IBM Software
Figure 71 – Validation Results
3. A new window will open with two access path graphs. Compare them and notice that the new plan is using the
nested loop join. Close the window.
Figure 72 – Access Plan comparison
7.4.6 Deploy Optimization Profile

1. Click the second icon, which is Deploy Optimization Profile.

IBM Software
Figure 73 – Deploy Optimization Profile
2. Enter OQT_PROFILE as the profile name and click Deploy.
Figure 74 – Schema and Optimization Profile Name
3. A new window will open. Scroll to the bottom, browsing through the script generated. Click OK to deploy this
optimization profile to the database.

IBM Software
Figure 75 – Deploy
4. Close QTProject1 as shown below. Click Yes to save changes.
Figure 76 – Close Tab
8 SQL Performance Tuning – Clean Up

Run the following script to reset your lab environment.
qtdir
. cleanup.sh

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.

IBM Software
DB2® Performance Clinic - Locking

Hands-On Lab
IBM Software
Table of Contents
1 Objectives.............................................................................................................................................................................................3
2 Lab Setup..............................................................................................................................................................................................3
2.1 Login to the Virtual Machine................................................................................................................................................................................3
2.2 Create the SAMPLE Database ...........................................................................................................................................................................4
2.3 Modifying Lab Environment.................................................................................................................................................................................4
3 Identifying Locking Issues..................................................................................................................................................................4

3.1 Enabling a locking event monitor (LOCKWAITS)................................................................................................................................................4
3.2 Using Snapshot Administrative Views.................................................................................................................................................................5
3.3 Review Details of Locking Report .......................................................................................................................................................................7
4 Event Monitor for Locking – Deadlock detection and formatting to relational tables..................................................................9
4.1 Create Event Monitor ........................................................................................................................................................................................10
4.2 Simulating deadlocks ........................................................................................................................................................................................10
5 Using Currently Committed Isolation Level ....................................................................................................................................12

5.1 Currently Committed Scenario ..........................................................................................................................................................................13
5.2 Without Currently Committed Isolation..............................................................................................................................................................14
5.2.1 Turning off Currently Committed.......................................................................................................................................................14
5.2.2 Execute an update query ..................................................................................................................................................................14
5.2.3 Execute a read query against the updated row ................................................................................................................................15
5.2.4 Releasing the lock.............................................................................................................................................................................16
5.3 With Currently Committed Isolation...................................................................................................................................................................16
5.3.1 Turning on Currently Committed.......................................................................................................................................................16
5.3.2 Execute an update query ..................................................................................................................................................................16
5.3.3 Execute a read query against the updated row ................................................................................................................................17
6 Summary.............................................................................................................................................................................................17
7 Scripts provided for this lab .............................................................................................................................................................18
7.1 snapdblocks.sql.................................................................................................................................................................................................18
7.2 lockwaits.sql ......................................................................................................................................................................................................18
7.3 createEventMonitorLocking.db2........................................................................................................................................................................18
7.4 call_EF.sh .........................................................................................................................................................................................................18

IBM Software
1 Objectives
After completion of this lab, the student should be able to:
Use snapshots, event monitors, administrative views and db2pd to identify locking issues through the reporting
provided by key monitoring elements.
Be able to identify the type of lock event causing a performance slowdown, identify the SQL statement(s) involved and
the locks being requested and encountered by applications.
2 Lab Setup
2.1 Login to the Virtual Machine
To access the lab environment, perform the following steps:

1. Login to the VMware virtual machine using the following information:
User: db2inst1
Password: password
3. Start up DB2 Server by typing “db2start” in the terminal window.

IBM Software
2.2 Create the SAMPLE Database

Before beginning the exercise, let’s create DB2’s SAMPLE database using the following command:
db2sampl –force
2.3 Modifying Lab Environment

It will be necessary to modify the default monitor switches at the instance level, so all snapshot administrative views will report
all monitor elements accurately.
db2 update dbm cfg using DFT_MON_LOCK on
The database used in this lab will need to have CUR_COMMIT turned off. CUR_COMMIT provides significant relief from locking
issues in a variety of scenarios.
Newly created databases will have the feature turned on by default. Any database updated from V9.5 or earlier will not have
CUR_COMMIT enabled.
db2 update db cfg for sample using CUR_COMMIT off

Let’s stop and restart the instance so are modified parameters are in effect before proceeding.
db2stop force
db2start
3 Identifying Locking Issues

3.1 Enabling a locking event monitor (LOCKWAITS)
So we may review detailed information about locking events we will create an event monitor for locking called lockevmon:
db2 connect to sample

db2 "CREATE EVENT MONITOR lockevmon
FOR LOCKING WRITE TO UNFORMATTED EVENT TABLE (TABLE lockwaits)"
db2 "set event monitor lockevmon state 1"
Update the DB CFG parameter MON_LOCKWAIT to control the amount of trace data and history to be captured.
HIST_AND_VALUES will include the contents of a history buffer. Alternatively, you can set the parameter to WITHOUT_HIST to
trace only the data about lock events when the lock event occurs and not any past activity history:
db2 update db cfg for sample using MON_LOCKWAIT hist_and_values

Update the DB CFG parameter to establish a threshold time limit of 5 seconds for how long the application is suspended in a
lock-wait status before being included in the report.
db2 update db cfg for sample using MON_LW_THRESH 5000000

IBM Software
3.2 Using Snapshot Administrative Views

Let’s take a look at a typical lock wait scenario. To simulate database activity open a terminal window and enter the following
commands:
lockdir (aliases cd /home/db2inst1/Documents/LabScripts/db2pt/Locking)

we –run –scn ~/Documents/LabScripts/db2pt/Locking/lockscenario.scn –db
localhost:50001/sample –u db2inst1 –p password
Wait for the scenario to give the indication that it has started and is actually running. Do not close this window. You can
minimize it since it will not be used until the end of the exercise.
After the scenario has been running for about 20 seconds, you should have collected enough data in the lock event monitor that
you started in section 3.1. To avoid having a large amount of data to browse through in the output file, you can turn the event
monitor off by setting it to 0. (Do NOT stop the Workload Expert scenario running in the first terminal window. You will need it
running for the next several exercises). Open a second terminal window, connect to the database, and enter:

db2 "set event monitor lockevmon state 0"
You can always query the database to see your event monitors, and whether they are on or off, by entering:
db2 "select evmonname, event_mon_state (evmonname) from

syscat.eventmonitors"
A database snapshot is a good place to start when investigating locking issues. The snapshot administrative view
SYSIBMADM.SNAPDB allows database level monitor elements to be returned via SQL SELECT statements. The use of queries
to retrieve snapshot monitor data allows filtering to focus on specific monitor data.
In the second terminal window, connect to the database and execute the following:

db2 -tf snapdblocks.sql
LOCK_WAITS DEADLOCKS LOCK_ESCALS LOCK_TIMEOUTS

---------------- ------------------ ------------------ ----------------
12 0 0 2
1 record(s) selected.
This query will return database level monitoring elements for each of the locking scenarios; lock waits, deadlocks, lock
escalations and lock timeouts. It is easy to see that LOCK WAITS are occurring. Why?
This can be explained by reviewing the database configuration.

IBM Software
db2 get db cfg for sample | grep LOCKTIMEOUT
Lock timeout (sec) (LOCKTIMEOUT) = -1
The DB CFG parameter LOCKTIMEOUT has not been changed from the default value of -1.
When LOCKTIMEOUT is set to -1 all LOCK WAIT conditions will wait indefinitely for the encountered lock to be released. Thus all
queries will become suspended in a lock-wait state until the lock encountered is released. If you plan on setting this parameter
to a specific time period, make sure that the application is prepared accordingly. DB2 will return an error code to the application
(SQL0911). From the command line interface it looks like this:
DB21034E The command was processed as an SQL statement because it was not a valid Command
Line Processor command. During SQL processing it returned:
SQL0911N The current transaction has been rolled back because of a deadlock or timeout.
Reason code "68". SQLSTATE=40001
db2 "select locks_held, lock_waits from sysibmadm.snapdb"
Sample Output:
db2inst1@db2v10:~/Documents/LabScripts/db2pt/Locking> db2 "select locks_held, lock_waits from
sysibmadm.snapdb"
LOCKS_HELD LOCK_WAITS
-------------------- --------------------
13 14
If the number reported under LOCK_WAITS is greater than zero, then that is the number of times that applications or
connections waited for locks.
To narrow the scope, and filter database locks to only the applications in a lock wait status, use the Snapshot administrative
view SYSIBMADM.MON_LOCKWAITS:
db2 -tf lockwaits.sql

IBM Software
TABSCHEMA TABNAME REQ_AGENT_TID LOCK_OBJECT_TYPE LOCK_MODE LOCK_MODE_REQUESTED

HLD_APPLICATION_HANDLE
--------- ---------- -------------- ------------------ ----------------------------- ----
DB2INST1 EMPLOYEE 43 ROW X X
19
DB2INST1 EMPLOYEE 42 ROW X NS
19
2 record(s) selected.
Some administrative views like SYSIBMADM.LOCKWAITS have been deprecated in DB2 10, so it is necessary to use new
administrative views like SYSIBMADM.MON_LOCKWAITS. You can review the following link:
http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.sql.rtn.doc/doc/r0023171.html
There are two applications waiting. Both have encountered an exclusive lock (X) placed by a third application. One is
attempting to acquire a X-lock, which would be expected when issuing an INSERT, UPDATE or DELETE; the other is
requesting a share (NS) which reflects a SELECT. MOVE THIS ENTIRE PARAGRAPH TO BELOW THE GREEN NOTE
ABOVE.
3.3 Review Details of Locking Report
To obtain the locking event report, use the db2evmonfmt tool. This tool is included with DB2 but is not compiled. You will find the
source in the Instance’s home directory under samples/java/jdbc.
For more details refer to the “db2evmonfmt tool for reading event monitor data” topic in Information Center v10.
For this lab, the utility has already been compiled and is in the Locking directory. Redirect the output to a file name to ease
review using a text editor.
~/sqllib/java/jdk32/jre/bin/java db2evmonfmt -d sample -ue lockwaits

-ftext -u db2inst1 -p password > db2evmonfmt.out

IBM Software
Figure 2 – db2evmonfmt output
Note: You can find the db2evmonfmt.out output file in ~/sqllib/java/jdk32/jre/bin/java directory.
Switch to the terminal running Workload Expert and enter quit to stop the process:
quit
As good practice, so that the lab can be rerun, turn off and drop the event monitor lockevmon, and drop the lock event table
lockwaits:
db2 set event monitor lockevmon state 0

db2 drop event monitor lockevmon
db2 drop table lockwaits
In order to continue with the next exercise is necessary to update the DB CFG parameter MON_LOCKWAIT with its previous
value:
db2 update db cfg for sample using MON_LOCKWAIT none

db2stop force
db2start

IBM Software
4 Event Monitor for Locking – Deadlock detection and formatting to relational

tables
In previous releases of DB2, pre-V9.7, if you wanted to capture deadlock events, you had to issue the CREATE EVENT
MONITOR FOR DEADLOCKS statement or check the output files written by the DB2DETAILDEADLOCK event monitor.
Now if you want to monitor deadlock events in DB2 10, using the CREATE EVENT MONITOR FOR LOCKING statement is the
recommended method. This event monitor not only monitors for deadlocks but also lock timeouts and excessive lock wait
occurrences.
In the previous exercise, you used this same approach (event monitor for locking) when monitoring lockwaits, now we will
focus on deadlocks. Previously we used the db2evmonfmt tool to generate formatted output and details about the
lockwaits, in this exercise you will use a system based stored procedure to store this information in a set of relational tables
then query these tables.
In this exercise you will:
1. Create the event monitor for locking. Output for this monitor is generated in the unformatted event (UE) table structure.
The create statement can specify placement of the UE table in a separate tablespace, a preferable technique to use
when you want to reduce I/O contention.
2. Generate transactions that will create deadlocks. The deadlock events will be written out to the UE tables
3. Format UE table data into relational table structure using a stored procedure developed expressly for this purpose.
4. Use SQL, via a script, to query the relational tables.
Start deadlock scenario Create

we –run –scn deadlock.scn Event Monintor for
Locking
evmon_format_ue_to_tables
('LOCKING', NULL, NULL,
Deadlocked Event Monitor NULL, NULL, NULL, call_EF.sh
Applications “Mylocks” 'RECREATE_FORCE', -1,
for Locking 'SELECT * FROM MYLOCKS
ORDER BY EVENT_TIMESTAMP')"
SQL Analysis
MYLOCKS
(Unformatted
Event Table) “LOCK”
Event relational
tables
Figure 3 – Exercise diagram

IBM Software
4.1 Create Event Monitor
First you will execute a DB2 script file to create the event monitor for locking. Open up a terminal window and change your
current directory to:
lockdir (aliases cd /home/db2inst1/Documents/LabScripts/db2pt/Locking/)
Before executing, take a look at the script; first the old event monitor is disabled, then an event monitor for locking is created
with specific designations for the table name (mylocks) and table space location (userspace1) before the new monitor is
turned on.
less createEventMonitorLocking.db2
Figure 4 – createEventMonitorLocking.db2 script
Connect to the database and execute the script:

db2 –tvf createEventMonitorLocking.db2
Note: Ignore the SQL0204N errors; they are a result of DROP statements which precede the CREATE and SET statements in the
script so you can repeat execution.
4.2 Simulating deadlocks
In a second terminal window, launch a workload simulation that will accumulate deadlocks. Locking information will be collected
in the unformatted event tables (UE).

IBM Software
In a second terminal window, enter the following commands:

we –run –scn ~/Documents/LabScripts/db2pt/Locking/deadlock.scn –db
localhost:50001/sample –u db2inst1 –p password --deadlockpairs 2
Let this scenario run for 15-20 seconds before entering “quit” to return to the operating system prompt:
quit
Figure 5 – Workload Expert output
Now check that deadlocks were generated and captured into the mylocks table (defined in create event monitor statement).

db2 "select count(*) from mylocks"
You should see a count of some rows in the mylocks table. (If you don’t, try re-executing the deadlock scenario).
Since the mylocks table is unformatted, you will execute a stored procedure to format the table into relational tables.
Use the call_EF.sh script to invoke EVMON_FORMAT_UE_TO_TABLES stored procedure. Three tables will be created to store
the unformatted data in a relational format: LOCK_EVENT, LOCK_PARTICIPANTS and LOCK_PARTICIPANT_ACTIVITIES.
./call_EF.sh
code in call_EF.sh :
db2 “connect to sample”

db2 “call evmon_format_ue_to_tables(‘LOCKING’, NULL, NULL, NULL, NULL,
NULL, ‘RECREATE_FORCE’, -1, ‘SELECT * FROM MYLOCKS ORDER BY
EVENT_TIMESTAMP’)”
Be sure to look for “Return Status = 0”.

IBM Software
Figure 6 – call_EF.sh output
The last step is to query the newly created (and populated) relational tables. You can use a provided script that will pick out the
first ID (xmlid) that is returned from the LOCK_EVENT table and query the other tables based on that ID.

./query_lockevent_tables.sh
Figure 7 – query_lockevent_tables.sh output
The query’s result displays the participants in a deadlock event, the application(s) that were involved, the SQL code, and
isolation levels used. This data provides a “good start” to resolving a deadlock issue.
Remember to quit the simulation workload by entering “quit” to return to the operating system prompt:
quit
5 Using Currently Committed Isolation Level

Lock timeouts and deadlocks can occur under the cursor stability (CS) isolation level with row-level locking, especially with
applications that are not designed to prevent such problems. Some high throughput database applications cannot tolerate
waiting on locks that are issued during transaction processing, and some applications cannot tolerate processing uncommitted
data, but still require non-blocking behavior for read transactions.

IBM Software
Under the Currently Committed isolation level, only committed data is returned, as was the case previously, but now readers do
not wait for updaters to release row locks. Instead, readers return data that is based on the currently committed version; that is,
data prior to the start of the write operation.
In DB2 10, Currently Committed is turned on by default for new databases. This allows any application to take advantage of the
new behavior without any modification. The database configuration parameter cur_commit can be used to override this
behavior. This might be useful, for example, in the case of applications that require the pre-9.7 behavior of blocking on writers
to synchronize internal logic. Upgraded databases have cur_commit disabled by default.
Currently Committed semantics apply only to read-only scans that do not involve catalog tables or the internal scans that are
used to evaluate constraints.
Note that, because Currently Committed is decided at the scan level, a writer's access plan might include Currently Committed
scans. For example, the scan for a read-only sub-query can involve currently committed semantics
Log data is required for retrieving the currently committed image of the row. Depending on the workload, this can have an
insignificant or substantial impact on the total log space and log buffer space required. The requirement for additional log space
does not apply when cur_commit is disabled.
5.1 Currently Committed Scenario
Consider the following scenario, in which deadlocks are avoided under the Currently Committed isolation level. In this scenario,
two applications update two separate tables, but do not commit. Each application then attempts to read (with a read-only cursor)
from the table that the other application has updated.
Time Transaction A Transaction B

1 update T1 set col1 = ? where col2 = ?
2 update T2 set col1 = ? where col2 = ?
3 select col1, col5, from T1 where col5 = ? and
col2 = ?
waiting for A to commit
4 select col1, col3, col4 from T2 where
col2 >= ?
waiting for B to commit
Without Currently Committed, transactions running under the Cursor Stability isolation level might create a deadlock, causing
one of the transactions to fail. This happens when each transaction needs to read data that is being updated by the other.
Using Currently Committed, if the query (of either application) happens to require the data currently being updated by the other
transaction, that transaction does not wait for the lock to be released, avoiding a deadlock since the previously committed
version of the data is located and used.

IBM Software
5.2 Without Currently Committed Isolation
In this lab, we’ll demonstrate the effect of the Currently Committed feature. To do so, we will create a scenario where a potential
read / write block can happen when 2 queries are running concurrently. We will then compare the difference in results and
execution time as we toggle the parameter CUR_COMMIT.
We will use command line processor (CLP) to simulate the applications accessing the database at the same time.
5.2.1 Turning off Currently Committed
First, let’s examine the existing setting for currently committed. From within a Terminal window, type in the following:
db2 get db cfg for sample
The CUR_COMMIT parameter is located near the end of the list. It should display as DISABLED, since we turned it off earlier in
the exercise. If it is ON, disable it by issuing the following command:
db2 update db cfg for sample using CUR_COMMIT disabled
After changing the value, we need to disconnect all connections, thus deactivating the database and allowing for the new value
to take effect upon the next activation or connect.
In both terminal windows, issue a connect reset:
In the first terminal window:
db2 connect reset
In the second terminal window:
db2 connect reset
5.2.2 Execute an update query
In order to mimic the behavior of a long running transaction, we first need to disable CLP’s auto-commit feature, which is ON by
default. When auto-commit is active, CLP automatically issues a COMMIT after every executed SQL statement. Therefore, we
need to disable it so we are able to specify when the transaction will be committed. In terminal A, enter the CLP prompt by
typing the command below. The “+c” option will disable the auto-commit feature for this session.
export DB2OPTIONS="+c"
You can check that the auto-commit feature is off by executing the command below:
db2 list command options

IBM Software
Figure 8 – List command options
Since auto-commit is OFF, from now on all SQL statements that you execute will be part of the same transaction until you issue
a “commit” or “rollback”. Now, connect to the database:
We will then execute an update query which will put a lock on the rows for as long as the transaction is not committed.
db2 "update employee set lastname = ‘Porter’ where empno = ‘000340’"
5.2.3 Execute a read query against the updated row

Terminal B will act as the second application trying to access the table. Similar to the first terminal, we will connect to the
database “sample” as user “db2inst1” with password “password” by typing in the command:
Next, we will launch a query that will read the data locked by Terminal A.
time db2 "select empno, firstnme, lastname from employee"
The time command will allow us to quantify the wait time. We can see that the query waits and does not return any result. In
fact, it is waiting on the locks of the first terminal window’s UPDATE statement to be released.

IBM Software
5.2.4 Releasing the lock
With the two terminal windows open beside each other, we will observe the effect of committing the UPDATE of the first terminal
window. In Terminal A, commit the transaction by executing the following command:
db2 commit
You can see the second terminal windows query is instantly returned with the updated values. The locks placed by the first
terminal window’s update have been released with the issuance of the commit statement.
5.3 With Currently Committed Isolation

We will repeat the procedure again but this time with the Currently Committed feature turned on. The objective to see the
difference in the time it took for the second query to return and the actual values being returned.
5.3.1 Turning on Currently Committed

In Terminal A, we will use the command to turn on currently committed:
db2 update db cfg for sample using CUR_COMMIT on
Figure 9 – Update parameter output
After changing the value, we need to disconnect all connections thus deactivating the database allowing for the new value to
take effect upon the next activation.
In both terminal windows issue a connect reset: In the first terminal window:
db2 connect reset

In the second terminal window, execute:
db2 connect reset
5.3.2 Execute an update query

Now, let’s create the exact same scenario. Similar to the previous section, update a row of data in the table in the first terminal
window and attempt to access the same row in the second terminal window.
In the first terminal window:

db2 "update employee set lastname = ‘Selleck’ where empno = ‘000340’"

IBM Software
5.3.3 Execute a read query against the updated row
In the second terminal window, reconnect to the database and try to retrieve the values from the table:

time db2 "select empno, firstnme, lastname from employee"
Notice the amount of time the query took to return this time. The query returned instantly because there was no access block to
the data. Also, notice the values returned were not from the most recent update since the update has not yet been committed,
but from the last committed update.
In Terminal A, commit the update by typing in the command
db2 commit
Switch the focus back to Terminal B. We want to execute the selection query again by pressing the up arrow button once to
retrieve the last executed command, and then press Enter. If you cannot find the last command, type in
time db2 "select * from employee"
Notice the values returned this time reflects our last update since the transaction in terminal A has ended and the updates
committed to the database.
To finalize the lab, enable auto-commit so that CLP will automatically issues a COMMIT after every executed SQL statement. Do
that by typing the command below. The “-c” option will enable the auto-commit feature for this session.
export DB2OPTIONS="-c"
You can check that the auto-commit feature is off by executing the command below:
db2 list command options
Terminate the database connections in the first terminal window:
db2 connect reset
Then, terminate the database connection in the second terminal window:

db2 connect reset
6 Summary
You can now identify and diagnose locking issues that can affect the performance of your databases and applications.
Now you have some tips which you can apply in your environment in order to design better databases to avoid locking issues.
Now you can use DB2 tools such as event monitors and administrative views to monitor your databases.

IBM Software
7 Scripts provided for this lab

The source for the scripts used in this workshop is provided here for you to copy/paste into your own environment. You might
need to modify them to meet your specific environment.
7.1 snapdblocks.sql
#------------------------------------------------------------------------------------------
SELECT LOCK_WAITS, DEADLOCKS, LOCK_ESCALS, LOCK_TIMEOUTS FROM SYSIBMADM.SNAPDB;
7.2 lockwaits.sql
SELECT SUBSTR(TABSCHEMA,1,8) AS TABSCHEMA,
SUBSTR(TABNAME,1,15) AS TABNAME,
REQ_AGENT_TID,
LOCK_OBJECT_TYPE, LOCK_MODE,
LOCK_MODE_REQUESTED,
HLD_APPLICATION_HANDLE
FROM SYSIBMADM.MON_LOCKWAITS;
7.3 createEventMonitorLocking.db2
-- This will shutdown the old default deadlock monitor
set event monitor db2detaildeadlock state 0;
-- This will shutdown mylocks so that lab can be rerun
set event monitor mylocks state 0;
-- Clean up just in case ok if this statement fails
drop event monitor mylocks;
drop table mylocks;
-- Create new event monitor for locking
create event monitor mylocks for locking write to unformatted event
table(table mylocks in userspace1);
set event monitor mylocks state 1 ;;
7.4 call_EF.sh
#------------------------------------------------------------------------------------------
db2 "connect to db2pt97"
db2 "call evmon_format_ue_to_tables('LOCKING', NULL, NULL, NULL, NULL, NULL,
'RECREATE_FORCE', -1, 'SELECT * FROM MYLOCKS ORDER BY EVENT_TIMESTAMP')"
exit

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.

IBM Software
DB2® Performance Clinic - Logging

Hands-On Lab
IBM Software
Table of Contents
1 Objectives of This Lab ........................................................................................................................................................................3

2 Setup and Start DB2 ............................................................................................................................................................................3
2.1 Login to the Virtual Machine ............................................................................................................................................................................... 3
2.2 SAMPLE Database ............................................................................................................................................................................................. 3
3 Configure the database for Archive Logging ...................................................................................................................................4

3.1 Create locations for archived logs....................................................................................................................................................................... 4
3.2 Activate the LOGARCHCOMPR1 ....................................................................................................................................................................... 6
4 Relocating Transaction Logs .............................................................................................................................................................6

4.1 Simulating Database Activity .............................................................................................................................................................................. 6
4.2 Relocating Log Files ........................................................................................................................................................................................... 8
5 Insufficient Log Space ......................................................................................................................................................................10

5.1 Configuring the initial number of Log Files........................................................................................................................................................ 10
5.2 Increasing the Number of Logs......................................................................................................................................................................... 10
6 Summary ............................................................................................................................................................................................12
7 Cleanup...............................................................................................................................................................................................12

IBM Software
1 Objectives of This Lab

After completion of this lab, the student should be able to:
• Identify performance issues relating to the database’s transaction logs.
• Be able to remedy the common issues relating to the database’s transaction logs which contribute performance
degradation.
2 Setup and Start DB2

2.1 Login to the Virtual Machine
To access the lab environment, perform the following steps:
• Login to the VMware virtual machine using the following information:

User: db2inst1
Password: password
Open a terminal window as by right-clicking on the Desktop area and choose the “Open Terminal” item.
Start up DB2 Server by typing “db2start” in the terminal window.
2.2 SAMPLE Database
This lab will utilize the SAMPLE database. To create (or re-create) the database, enter the following command in a terminal
window:
db2sampl –force –sql

IBM Software
And observe the following output:
Figure 2 – Creating a SAMPLE database
3 Configure the database for Archive Logging

3.1 Create locations for archived logs
Update the DB2 database configuration parameter LOGARCHMETH1 to begin archiving the active logs to a local disk. Reduce the
transaction log buffer (logbufsz) to a low value to help create a poorly performing configuration. Use DEACTIVATE
DATABASE command to deactivate the database for the change to take effect. Then use the ACTIVATE DATABASE command
to reactivate the database.
Forward Recovery must be enabled for the database. Forward Recovery is placed into effect by setting either of the two DB
CFG parameters LOGARCHMETH1 or LOGARCHMETH2 and then performing an offline backup of the database.
In the terminal session, issue the commands:
db2 UPDATE DB CFG FOR sample USING LOGARCHMETH1 DISK:/archive

db2 UPDATE DB CFG FOR sample USING logbufsz 64
db2 FORCE APPLICATION ALL
db2 TERMINATE
db2 DEACTIVATE DB sample
db2 BACKUP DB sample TO /backup COMPRESS
Before continuing, verify that Archive Logging is enabled by taking a second database backup, but this time includes the
ONLINE option. Only when Archive Logging is enabled can an online backup be performed.
In the terminal session, issue the command:
db2 CONNECT TO sample

db2 BACKUP DATABASE sample ONLINE TO /backup COMPRESS

IBM Software
Figure 3 – Offline database backup
With Archive Logging enabled, the Online Backup should have truncated and archived the current transaction log. In the
terminal session, issue the command Verify the path has been changed. Issue this command:
db2 list history archive log all for SAMPLE
List History File for SAMPLE

Number of matching file entries = 1
Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID

-- --- ------------------ ---- --- ------------ ------------ --------------
X D 20120402194209 1 D S0000000.LOG C0000000
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Comment:
Start Time: 20120402194209
End Time: 20120402194643
Status: A
----------------------------------------------------------------------------
EID: 3 Location:
/home/db2inst1/archive/db2inst1/SAMPLE/NODE0000/LOGSTREAM0000/C0000000/S0000000.LOG
Note: your date values will be different.

IBM Software
3.2 Activate the LOGARCHCOMPR1

db2 UPDATE DB CFG FOR sample USING LOGARCHCOMPR1 ON
LOGARCHCOMPR1: This parameter specifies whether the log files written to the primary archive destination for logs are
compressed.
4 Relocating Transaction Logs

4.1 Simulating Database Activity
To simulate database activity this exercise will utilize a Workload Expert script.
Open a terminal window and enter the following on one line:
we –run –scn ~/Documents/LabScripts/db2pt/Logging/logscenario.scn –db

Leave the workload simulation running, open another terminal window and use the iostat utility to monitor I/O activity:
iostat –t 3
Figure 4 – use iostat to monitor I/O activites
Note: Your values could be different.

IBM Software
The iostat will repeatedly display every 3 seconds until you enter Control-C to terminate. You will see that most of the I/O
activity is occurring on the /sda and /sdc file systems.
Enter Control-C to terminate iostat then issue the following command to see the mount point of /sda:
mount | grep sda
Figure 5 – Verifying the mount point of /sda
The sda device is mounted on the / file system.
Let’s query the database to see the location of the table spaces. You will notice they share the same device as the transaction
logs. In the terminal session, issue the following commands:

db2 "SELECT SUBSTR(TBSP_NAME,1,20) AS TBSP_NAME, INT(TBSP_ID) AS TBSP_ID,
SUBSTR(CONTAINER_NAME,1,65) AS CONTAINER_NAME
FROM SYSIBMADM.CONTAINER_UTILIZATION"
Figure 6 – Container Utilization
Next, identify the current location of the database log files:
db2 get db cfg for sample|grep -i "log file"

IBM Software
Figure 7 – Path to log files
Note the location of the transaction logs. By default, they are created on the same file system (and physical device) identified by
the database path (DBPATH). In this case, that is the same path as the database’s table space containers.
4.2 Relocating Log Files

Stop the Workload Expert scenario by entering ‘quit’ in the terminal window and terminate the connection.
quit
db2 terminate
Then use the DB CFG parameter NEWLOGPATH to change the location:
db2 update db cfg for sample using NEWLOGPATH /logs

db2 terminate
db2 deactivate database sample
Figure 8 – Update with a log path
This will truncate and archive the current log file as well as remove any secondary log files. Once reactivated the database will
create log files in the new location.
db2 activate database sample

NEWLOGPATH is a string of up to 242 bytes which specifies a new location to change where the log files will be moved. This can
point to either a fully qualified path name or raw device.

IBM Software
After database activation, the log files now reside on the /logs file system located on /dev/sdf1. Restart the workload simulation
and observe the change using the iostat utility. Now, database disk activity will be observed on both sda, sda2 and sdb, sdb1
devices.
Open a terminal window and execute the following on one line:

Leave the workload simulation running, open another terminal window and use the iostat utility to monitor I/O activity:
iostat –t 3
Figure 9 – Use iostat to monitor I/O activities
Note: your values could be different.
Notice how significant I/O activity is on the transaction log files. Changing the log path to a separate local high-speed disk, which
is not in use for anything other than logging, can significantly improve performance. Enter Control-c to stop the IO stat process
and quit to end the Workload Expert scenario.

IBM Software
5 Insufficient Log Space

5.1 Configuring the initial number of Log Files
The default configuration database will create log files capable of handling a significant volume of transactions so we need to
“shrink” the current configuration so the simulated workload will experience insufficient log space.
Override the default minimums and update the database configuration with parameter values too small for the workload.

db2 terminate
db2 deactivate db sample
db2 update db cfg for sample using logprimary 2
db2 update db cfg for sample using logsecond 0
db2 update db cfg for sample using logfilsiz 100
db2 activate db sample
Figure 10 – Update logging configuration parameters
5.2 Increasing the Number of Logs

Using Workload Expert, start the Logging SQL scenario (logscenario.scn). Open a terminal window and execute the following:

Within a short period of time, SQL process will be aborted due to a log-full condition:

IBM Software
Figure 11 – Transaction log full
The available log space, i.e. (LOGPRIMARY + LOGSECOND) * LOGFILSIZ, is not enough to keep up with the number of
transactions being processed.
Let’s establish a more reasonable value to LOGFILSZ parameter, and add more primary log and secondary log files. In the
terminal session, issue the command:
db2 update db cfg for sample using LOGPRIMARY 10

db2 update db cfg for sample using LOGSECOND 2
db2 update db cfg for sample using LOGFILSIZ 1000
db2 terminate
db2 deactivate db sample
db2 activate db sample
The increased capacity for transaction log records will now permit the SIMPLESQL scenario to execute until the script is
terminated.
Figure 12 – Reconfigure space for logs

IBM Software
Restart the scenario, this time it will be necessary for you to enter “quit” to abort the script’s execution.

6 Summary
You can now identify and diagnose performance issues relating to the database’s transaction logs.
Now you be able to remedy the common issues relating to the database’s transaction logs which contribute performance
degradation
7 Cleanup

db2 terminate
db2 drop db sample
db2stop

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.
IBM Software
DB2® Maintenance Utilities and Performance

Hands-On Lab
IBM Software
Table of Contents
1 Introduction ..........................................................................................................................................................................................3
3 Lab Setup..............................................................................................................................................................................................3
4 Create Database...................................................................................................................................................................................4
4.1 Create Database .................................................................................................................................................................................................4
4.1.1 Activate the Database.........................................................................................................................................................................5
4.2 REORGCHK, REORG and RUNSTATS.............................................................................................................................................................6
4.2.1 REORGCHK .......................................................................................................................................................................................6
4.2.2 REORG ...............................................................................................................................................................................................8
4.2.3 RUNSTATS.........................................................................................................................................................................................8
5 Configure Utility Performance ..........................................................................................................................................................10

5.1 Utility Throttling .................................................................................................................................................................................................10
5.2 Backup ..............................................................................................................................................................................................................11
5.3 EXPORT Utility..................................................................................................................................................................................................18
5.4 IMPORT Utility...................................................................................................................................................................................................20
5.4.1 ALLOW NO|WRITE ACCESS...........................................................................................................................................................20
5.4.2 COMMITCOUNT n AUTOMATIC .....................................................................................................................................................20
5.5 INGEST Utility ...................................................................................................................................................................................................22
5.6 LOAD utility .......................................................................................................................................................................................................26
SAVECOUNT n.................................................................................................................................................................................27
DATA BUFFER buffer – size ............................................................................................................................................................27
SORT BUFFER buffer - size.............................................................................................................................................................27
CPU_PARALLELISM n .....................................................................................................................................................................27
DISK_PARALLELISM .......................................................................................................................................................................27
FETCH_PARALLELISM ...................................................................................................................................................................27
INDEXING MODE .............................................................................................................................................................................27
ALLOW NO|READ ACCESS ............................................................................................................................................................27
LOCK WITH FORCE ........................................................................................................................................................................27
6 Further maintenance utility discussions.........................................................................................................................................28

7 Cleanup...............................................................................................................................................................................................29

IBM Software
1 Introduction
DB2 10 contains innovative features for delivering information on demand and scaling databases to new levels.
In this lab, you will learn about
• Automatic tuning DB2 performs for you when you use utilities
• Manual tuning considerations and options for utilities
• Monitoring the utilities DB2 provided for maintaining the integrity of your data
• Features and facilities available for configuring and monitoring the performance of DB2 and your applications
Performance and security are often left out of initial design considerations for new or migrated databases. We will address these
as we proceed through the workshop.
Some of the information in this document has been taken directly from the DB2 Version 10 Information Center. The information
may or may not have been modified for the purposes of this document.
2 Suggested Reading
Contains articles and tutorials
http://www.ibm.com/developerworks/views/data/libraryview.jsp
An Expert's Guide to DB2 Technology

Great read and useful information
http://it.toolbox.com/blogs/db2luw
DS4000 Best Practices and Performance Tuning Guide

http://www.redbooks.ibm.com/abstracts/sg246363.html
3 Lab Setup
Power on the virtual machine. Login as db2inst1. The password is password. Many of the commands you use to configure
performance for DB2 can be quite long and complicated. We've put these commands into text files so you don't have to do as
much typing in this lab. Please review each shell script or SQL file before you use it. To make it easier to review the code you'll
be executing throughout the lab, open of the files with SQL extension in an editor. Write permission for these files has been
removed so you won't damage them while they're open in the editor. Alternatively, refer to the end of this document for the
source code.
IBM Software
• Click Computer on the task bar (lower left corner).
• Click the More applications... pushbutton.
• Click Tools in the left navigation pane.
• Click the gedit text editor icon in the right pane.
• Click File -> Open on the menu bar.
• Navigate to the next directory:
/home/db2inst1/Documents/LabScripts/db2pt/utilities
• Select all the files with SQL extension in the directory and click the Open pushbutton.
4 Create Database
In this section we will create our database from a backup.
4.1 Create Database
In the previous exercise we placed our database logs in directory /logs. This directory will be reused in this exercise. Therefore,
remove any old log files in this directory:

IBM Software
rm –rf /logs/*
We provide a script that contains the commands to create the database by restoring a backup of the xmldb database. Open a
terminal session and enter the following commands to restore the database and the database objects needed for the lab
exercises.
cd ~/Documents/LabScripts/db2pt/utilities
db2start
db2 -tvf restoreXMLdb.sql
4.1.1 Activate the Database
Deployment consideration: Database buffer pools, agents and other objects are not allocated in memory until the database is
activated or an application connects to the database.
If a database has not been activated, the first application to connect to the database will incur a performance penalty as it waits
for the database objects to be allocated and instantiated. In addition, when the last application disconnects from the database,
the database objects are de-allocated. This means the next application to connect to the database will have to wait until the
database objects are allocated. Another reason to activate the database is for monitoring purposes; performance metrics are
typically accumulated upon either activation or first connection to the database.
You can remove this performance inhibitor by activating the database when the system starts. Database objects will remain
allocated until the deactivate database command is issued. This will also give DB2's autonomic computing features the
best opportunity to provide their benefits. Refer to the activate database command for more information on this subject
db2stop
db2start
db2 activate db xmldb
db2 connect to xmldb

IBM Software
Figure 2 – Restore y Activate database
4.2 REORGCHK, REORG and RUNSTATS

Upon restoration of the database, the database will have newly created indexes on the table, db2inst1.xmlfiles. The indexes
were created to enhance application performance. However, our data is not arranged optimally in the tablespaces because the
indexes were created after the data was inserted. The utilities in this section will help us cluster the data based on the indexes,
compress the indexes and rebuild the compression dictionary.
4.2.1 REORGCHK
The REORGCHK command calculates statistics on the database to determine if tables, indexes or both need to be reorganized
or cleaned up.
We will run the reorgchk command twice. The first time we will use the current statistics for the database, and then we will
supply an option that will update the statistics and then check if a reorg is needed. Enter the following command on a single
line:
db2 reorgchk current statistics on table db2inst1.xmlfiles >reorgchk_1.txt

IBM Software
You can review the reorgchk command's results by opening the reorgchk_1.txt by displaying its contents with the cat, more or
less commands. Results during lab development showed that table did not require a reorg (F1 F2 F3 REORG results were ---),
but that an index reorg was recommended (F4 F5 F6 F7 F8 REORG results were *----).
cat reorgchk_1.txt
Figure 3 – REORGCHK output
The UPDATE STATISTICS parameter calls the RUNSTATS routine to update table and index statistics, and then uses the
updated statistics to determine if table or index reorganization is required. Run the command to update the statistics and review
the results. Enter the following command on a single line:
db2 reorgchk update statistics on table db2inst1.xmlfiles >reorgchk_2.txt
Results during lab development showed similar results for both commands, meaning that the statistics for this table were
already up-to-date. This is a small table with relatively simple statistics. Results for production databases may show that you
should use the UPDATE STATISTICS option for more accurate results, provided that you have a large enough window.
(RUNSTATS may be costly in terms of lapsed time and catalog locking.) Alternatively, you can enable automatic RUNSTATS, so
that DB2 will gather statistics in the background as needed.

IBM Software
4.2.2 REORG
The reorg command is used to reorganize (defragment) an index or a table. Running a reorg for indexes rebuilds the index
data into unfragmented, physically contiguous pages. Running a reorg for a table reconstructs, or rebuilds the rows, compacting
the table by eliminating fragmented data. In addition, you can rebuild the data compression dictionary and recompress the data
accordingly.
On a partitioned table, you can reorganize a single partition. You can reorganize a specific nonpartitioned index, or you can
reorganize all the partitioned indexes on a specific data partition.
If you specify the CLEANUP option of the index clause, cleanup of logically deleted indexes is performed without rebuilding the
indexes. This command cannot be used against indexes on declared temporary tables or created temporary tables (SQLSTATE
42995).
Enter the following commands to reorg the indexes and table data and create a new compression dictionary.
db2 reorg indexes all for table db2inst1.xmlfiles
db2 reorg table db2inst1.xmlfiles resetdictionary
4.2.3 RUNSTATS
There are two essential times you should execute the runstats utility against a table: after the table has had a lot of updates
or after you reorganize the table. You should execute the runstats utility against statistical views that have been enabled for
optimization when modifications to their underlying tables affect the rows returned by the views.
You do not need any explicit privilege to use this command on any declared temporary table that exists within its connection.
We want to update the statistics for the database because we have just run a reorg operation. We can base the statistics on a
sample, or percentage of the data in the table. DB2's runstats command offers two types of sampling: Bernoulli and system.
Bernoulli sampling evaluates a sample set of rows. System sampling evaluates a sample set of data pages. System sampling
introduces less overhead than Bernoulli sampling but may not produce as accurate results when your data is highly clustered.
In this example we specify the util_impact_priority parameter with its lowest value so it will run at a very low priority. We
specify “allow read access” so other applications will be able to access the data while the command runs. We specify 100 for
both the sampling method and the repeatable parameter so that every row (100 percent of the rows) will be analyzed. You will
probably want to use a much lower value for larger tables. You may need to compare results with no sampling to find the lowest
percentage that will yield “good” statistics. This can become critical to performance when hundreds of millions of rows exist.
Enter the following command to capture the new statistics for our database.
db2 -tvf runstats.sql

IBM Software
Figure 4 – REORGCHK, REORG, and RUNSTATS
The first reorg command we ran in the last section was for the indexes. Review that reorg command's results by running the
reogrchk command again, as shown below. Enter the following command on a single line:
db2 reorgchk update statistics on table db2inst1.xmlfiles >reorgchk_3.txt
Compare files reorgchk_2.txt and reorgchk_3.txt. There should no longer be any indexes needing a reorg
The second reorg command we ran in the last section reorganized the data, creating a new compression dictionary. Enter the
following command to display the current compression statistics. Record the results in to table below.
db2 –tvf checkCompression.sql
TYPE DICTIONARY PAGES BYTES

SAVED % SAVED %
DATA
XML
Table 1 XMLDB compression statistics after reorg and runstats

IBM Software
Figure 5 – REORGCHK and compression check
5 Configure Utility Performance

In the previous section we reviewed the RUNSTATS, REORG, REORGCHK. These utilities impact directly the runtime
performance of the database. In this section we will focus on the data management utilities for data movement.
5.1 Utility Throttling

Utility throttling regulates the performance impact of maintenance utilities, so that it is possible to run them concurrently during
production periods. Although the impact policy, a setting that allows utilities to run in throttled mode, is defined by default, you
must set an impact priority for each utility which you want to throttle.
The throttling system ensures that the throttled utilities are run as frequently as possible when necessary without violating the
impact policy. You can throttle statistics collection, backup operations, rebalancing operations, and asynchronous index
cleanups.
First, you define the impact policy by setting the UTIL_IMPACT_LIM configuration parameter.
Check the current setting for the impact policy with the following command.
db2 get dbm cfg | grep -i util
Figure 6 – UTIL_IMPACT_LIM

IBM Software
The value of the util_impact_lim parameter determines what impact all running utilities can have on the total database
workload. For example, if the value of this parameter is 10, then all running utilities together can have no more than a 10%
average impact upon the total workload for the database. If the value is set to 100, then no throttling will occur.
Refining this a bit further, you can manage the priority of individual utilities within the average impact allotment. For example,
you could give more resources to RUNSTATS and fewer to BACKUP, or vice versa. You use the UTIL_IMPACT_PRIORITY
clause of the RUNSTATS or BACKUP command to set the relative priority of an individual utility within the UTIL_IMPACT_LIM
percentage. If you omit the UTIL_IMPACT_PRIORITY clause, the utility runs unthrottled, regardless of the setting of
UTIL_IMPACT_LIM.
You may also use the SET UTIL_IMPACT_PRIORITY command or the db2UtilityControl API to enable throttling, or to set or
change the relative priority of an individual utility. By default, within the impact allotment, each utility has a utility impact priority
of 50 (acceptable values are between 1 and 100, with 0 indicating no throttling).
5.2 Backup
DB2 allows you to backup an entire database or selected tablespaces. You can perform a hot (online) or cold (offline) backup
depending on how the transaction logging is configured.
Data, backups, active transaction logs and archived transaction logs should be stored on separate physical devices for two
reasons:
• First, if you lose the active database you don't lose the backup and transaction logs, too. If you did there would be no
way to recover or restore the database.
• Second, disk I/O will not be a bottleneck as you read from the database and write to the backup and/or transaction logs.
We have configured separate drives for active transaction logs (/logs), archived transaction logs (/archive), and database
backups (/backups).
Let’s suppose that the Service Level Agreement (SLA) states that the database should remain online at all times except during
the quarterly maintenance periods. To reduce the amount of time it would take to recover a database after a disaster you should
perform a full database offline backup before putting the database online. Then you could take another full offline backup
during each maintenance period.
Before performing a backup operation we need to change transaction logging from circular mode to archival mode. This will
allow you to take an online backup of the database. In order to do this we need to set the logarchmeth1 parameter.
db2 update db cfg using logarchmeth1 disk:/archive
We have a disk drive set aside for transaction logs. Specify the new transaction log setting with the following command.
db2 update db cfg using newlogpath /logs

IBM Software
Figure 7 – Enable log archiving and move logs
The messages issued when you executed the previous commands indicate that the changes have not yet taken effect. We need
to terminate all connections to the database to activate the changes. To be certain, and since we aren't in production mode,
we'll also restart DB2. Enter the following commands to activate the logging changes.
db2 connect reset

db2 deactivate db xmldb
db2stop
db2start
Note: We cannot activate the database, nor can applications connect to the database, which is now in a BACKUP PENDING state.
A message to this effect is returned by the activate command and is also placed in the DB2 diagnostics log. By default, this log can be
found at ~/sqllib/db2dump/db2diag.log
Start a new terminal session or terminal session tab. We'll use it to monitor utilities as they run. Start a WHILE loop in the new
session. Press Enter after each of the following lines. This loop will return message SQL1611W when no utilities are running.
while true
do
db2 list utilities
sleep 5
done

IBM Software
Figure 8 – LIST UTILITIES
DB2 automatically calculates the numbers of buffers it needs for a backup and the parallelism to be used to read tablespaces
concurrently. DB2 records the actions it takes to optimize backup performance using its autonomic computing features in the
db2diag.log. Enter the following command to backup the database, and then switch to the other terminal session to monitor the
backup process.
db2 backup db xmldb to /backup compress
In the diagnostics log (/home/db2inst1/sqllib/db2dump/db2diag.log) you can see STMM modifying memory consumers
parameters. We observed, during the creation of the lab materials, that DB2 set the parallelism to 2 and used 4 backup buffers
of size 4096.

IBM Software
Figure 9 – db2diag.log
The output of the LIST UTILITIES command shows that the backup was unthrottled. It also gave us an estimated
percentage complete.

IBM Software
Switch to the terminal session tab that isn't monitoring activities. In this session you will activate the database (it's ready for
production use now), add more files to the database, and then perform an online backup which you will throttle. Add more data
with the following command.

./addFiles.sh

IBM Software
Figure 11 – Activate and add data
After the script completes, enter the following command on a single line to backup the database, and then switch to the other
terminal session to monitor the backup process. Providing the util_impact_priority clause and value will throttle the
backup operation.
db2 backup db xmldb online to /backup compress util_impact_priority 80

include logs
Figure 12 – online BACKUP
You should notice in db2diag.log that an online backup was started and the transaction log was archived. The WHILE loop
should show you that the backup was started in throttled mode using the percentage you supplied, and that specifying the
UTIL_IMPACT_PRIORITY on the BACKUP command changed to the priority to 80.

IBM Software
Note: Relationship between UTIL_IMPACT_LIM and UTIL_IMPACT_PRIORITY

The database manager configuration parameter UTIL_IMPACT_LIM sets the limit on the amount of impact throttled utilities can have on the
overall workload on the machine. 0-99 is a throttled percentage, 100 is no throttling.
UTIL_IMPACT_PRIORITY is set using the SET UTIL_IMPACT_PRIORITY command. It sets the priority that a particular utility has over the
resources available to throttled utilities as defined by UTIL_IMPACT_LIM. (0 = unthrottled)
Press Ctrl+C in this terminal session to cancel the WHILE loop.
In addition to the storage savings you can achieve through row compression in your active database, you can also use backup
compression to reduce the size of your database backups.
Whereas row compression works on a table-by-table basis, when you use compression for your backups, all of the data in the
backup image is compressed, including catalog tables, index objects, LOB objects, auxiliary database files and database meta-
data.
You can use backup compression with tables that use row compression. Keep in mind, however, that backup compression
requires additional CPU resources and extra time. It may be sufficient to use table compression alone to achieve a reduction in
your backup storage requirements. If you are using row compression, consider using backup compression only if storage
optimization is of higher priority than the extra time it takes to perform the backup.
Tip: Consider using backup compression only on table spaces that do not contain compressed data if the following conditions
apply:
• Data and index objects are separate from LOB and long field data, and

IBM Software
• You use row and index compression on the majority of your data tables and indexes, respectively
To use compression for your backups, use the COMPRESS option on the BACKUP DATABASE command.
5.3 EXPORT Utility

The EXPORT utility, or EXPORT option of the DB2MOVE utility, is cross-platform compatible. This utility is best suited for situations
where you want to store data in an external file, either to process it further or to move data to another table. You can export
large objects and XML columns in addition to relational data. DB2MOVE exports tables in PC/IXF format. If you want to save the
data in the delimited ASCII format you should use the EXPORT command instead of DB2MOVE.
The EXPORT command has no performance optimization parameters. There are a few ways to improve the export utility's
performance. As the export utility is an embedded SQL application and does SQL fetches internally, optimizations that apply to
SQL operations apply to the export utility as well. Consider taking advantage of large buffer pools, plus indexing and sort heap if
a WHERE clause is used. In addition, try to minimize device contention on the output files by placing them away from the
containers and log devices. Large objects and XML files can be exported in round robin fashion by specifying multiple
directories.
EXPORT does not move database objects associated with the tables such as aliases, views, or triggers, or the objects tables
may depend on, such as user-defined types or user-defined functions. You will need to manually move these objects. They can
be created with the DB2LOOK command.
Create a directory to store the extracted data in and list the number of records in the table with the following commands.
mkdir /tmp/db2move
cd /tmp/db2move
db2 "select count(*) from reldata"
db2 connect reset
Figure 14 – Query into table RELDATA

IBM Software
Choose one of the following commands to export the data. Both versions of this command should create identical output
and results. Notice that the DB2MOVE command syntax is simpler. The EXPORT command should be entered on a single line.
Either:
db2move xmldb export -tn reldata
Or:
db2 "export to tab1.ixf of ixf messages tab1.msg select * from reldata"
Figure 15 – Export Data with db2move
You can review the files created by the EXPORT command with the following commands. The EXPORT.out file is available if you
used the DB2MOVE command.
ls
cat EXPORT.out
cat tab1.msg
Delete the data in the table and verify the records have been deleted with the following commands.
db2 truncate table reldata reuse storage immediate
db2 connect reset

IBM Software
Figure 16 – Truncate table RELDATA
5.4 IMPORT Utility

The IMPORT utility, or IMPORT option of the DB2MOVE utility, is cross-platform compatible. The IMPORT utility inserts data from
an external file with a supported file format into a table, hierarchy, view or nickname. The LOAD utility is a faster alternative, but it
does not support loading data at the hierarchy level.
You can improve the performance of the IMPORT utility if the data is on separate drives from the log files and tablespace
containers. You can reduce the impact to other applications by importing individual tables or doing hierarchical imports when
system utilitization is lower. The following two parameters impact the performance of this utility.
5.4.1 ALLOW NO|WRITE ACCESS
ALLOW NO ACCESS is the default for IMPORT operations. DB2 will acquire an exclusive (X) lock on the table before any rows
are inserted. In this case, the table is considered to be offline to other applications and they will not be able to access the table
or its contents. This allows for the fastest IMPORT operation.
Specifying WRITE causes the IMPORT to run in online mode, allowing other applications to access the table. There are several
IMPORT options which are not compatible with online mode. These are REPLACE, CREATE, or REPLACE_CREATE.
Additionally, online mode is not compatible with buffered inserts.
5.4.2 COMMITCOUNT n AUTOMATIC
The COMMITCOUNT parameter specifies how frequently the data is to be written to disk. IMPORT performs a COMMIT after every
n records are imported if a number is provided. When AUTOMATIC is specified, IMPORT determines when a commit needs to be
performed. The IMPORT utility will automatically commit for either one of two reasons:

IBM Software
• to avoid running out of active log space
• to avoid lock escalation from row level to table level
If the ALLOW WRITE ACCESS option is specified and the COMMITCOUNT option is not specified, the IMPORT utility will perform
commits as if COMMITCOUNT AUTOMATIC had been specified.
In order to meet our SLA we need to keep the database online. Import the data back into the reldata table using the following
commands and performance options. The IMPORT command should be entered on a single line.

db2 import from tab1.ixf of ixf allow write access commitcount 50 messages
import.msg insert into reldata
db2 connect reset
Figure 17 – Importing data back into table RELDATA
There should be a message for each COMMIT the IMPORT utility made after each 50 rows, and when the operation ended.
less import.msg
Press ‘q’ on your keyboard to quit viewing import.msg.
For reference, notice that the DB2MOVE command syntax is much simpler than the IMPORT command. DB2MOVE will use the
information in file db2move.lst to determine which files and tables to access.
Note: DO NOT EXECUTE THIS COMMAND
db2move xmldb import -io insert

IBM Software
5.5 INGEST Utility

The ingest utility (sometimes referred to as continuous data ingest, or CDI) is a high-speed client-side DB2® utility that streams
data from files and pipes into DB2 target tables. Because the ingest utility can move large amounts of real-time data without
locking the target table, you do not need to choose between the data currency and availability.
The ingest utility ingests pre-processed data directly or from files output by ETL tools or other means. It can run continually and
thus it can process a continuous data stream through pipes. The data is ingested at speeds that are high enough to populate
even large databases in partitioned database environments.
An INGEST command updates the target table with low latency in a single step. The ingest utility uses row locking, so it has
minimal interference with other user activities on the same table.
With this utility, you can perform DML operations on a table using an SQL-like interface without locking the target table. These
ingest operations support the following SQL statements: INSERT, UPDATE, MERGE, REPLACE, and DELETE. The ingest
utility also supports the use of SQL expressions to build individual column values from more than one data field.
Other important features of the ingest utility include:
• Commit by time or number of rows
• Support for copying rejected records to a file or table, or discarding them
• Support for restart and recovery
The INGEST command supports the following input data formats:

• Delimited text
• Positional text and binary
• Columns in various orders and formats
A single INGEST command goes through three major phases:
1. Transport
2. Format
3. Flush
During this exercise we will just replace data into a table using import, ingest and load, each one several times to see and
compare execution times.
Depending on hardware infrastructure, you may reach to the conclusion that the fastest one is LOAD. However, INGEST not
only is as fast as IMPORT, but also has the option to automatically restart from the point of cancellation if it occurs. If we disable
this functionality in INGEST, it will run twice as fast as IMPORT. Furthermore, INGEST can input data from several files at the
same time, or from pipes, etc.

IBM Software
We first need to create the table that INGEST tool uses for restart information, and the table that we will use for our example, to
input data:
Open a terminal window and execute the following commands:
cd ~/Documents/LabScripts/db2pt/utilities
./compare_times.sh
You will see output similar to the results below (result times may vary depending on the physical machine where VMware
resides). Notice the execution time for each operation:

Database server = DB2/LINUX 10.1.0
Local database alias = XMLDB
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
SQL3501W The table space(s) in which the table resides will not be placed in backup pending
state since forward recovery is disabled for the database.
SQL3418W The NOCHARDEL file type modifier should not be specified if the data was exported
using DB2. It is provided to support vendor data files that do not have character delimiters.

IBM Software
STARTING LOAD
SQL3109N The utility is beginning to load data from file
"/home/db2inst1/Documents/LabScripts/db2pt/utilities/ingest_data_200k".
SQL3500W The utility is beginning the "LOAD" phase at time "03/23/2012
13:57:07.219370".
SQL3519W Begin Load Consistency Point. Input record count = "0".
SQL3520W Load Consistency Point was successful.
SQL3110N The utility has completed processing. "200000" rows were read from
the input file.
SQL3519W Begin Load Consistency Point. Input record count = "200000".
SQL3520W Load Consistency Point was successful.
SQL3515W The utility has finished the "LOAD" phase at time "03/23/2012
13:57:11.797938".
Number of rows read = 200000

Number of rows skipped =0
Number of rows loaded = 200000
Number of rows rejected =0
Number of rows deleted =0
Number of rows committed = 200000
real 0m2.632s
user 0m0.004s
sys 0m0.008s
STARTING INGEST UTILITY
SQL2979I The ingest utility is starting at "03/23/2012 13:57:14.571600".
SQL2914I The ingest utility has started the following ingest job:

IBM Software
"DB21001:20120323.135714.571600:00003:00006".

Number of rows inserted = 200000
SQL2980I The ingest utility completed successfully at timestamp "03/23/2012
13:57:28.934178"
real 0m14.512s
user 0m0.004s
sys 0m0.008s
SQL2979I The ingest utility is starting at "03/23/2012 13:57:29.156538".
SQL2914I The ingest utility has started the following ingest job:
"DB21001:20120323.135729.156538:00003:00006".

SQL2980I The ingest utility completed successfully at timestamp "03/23/2012
13:57:40.456536"
real 0m11.531s
user 0m0.008s
sys 0m0.008s
SQL3109N The utility is beginning to load data from file "ingest_data_200k".
SQL3418W The NOCHARDEL file type modifier should not be specified if the data
was exported using DB2. It is provided to support vendor data files that do

IBM Software
not have character delimiters.
SQL3110N The utility has completed processing. "200000" rows were read from
the input file.
SQL3221W ...Begin COMMIT WORK. Input Record Count = "200000".
SQL3222W ...COMMIT of any database changes was successful.
SQL3149N "200000" rows were processed from the input file. "200000" rows
were successfully inserted into the table. "0" rows were rejected.

Number of rows skipped =0
Number of rows updated =0
Number of rows committed = 200000
real 0m19.712s
user 0m0.004s
sys 0m0.008s
Figure 18 – IMPORT/INGEST OUTPUT
As you can see, the execution time of IMPORT and INGEST with restart capability is almost the same, but INGEST provides the
functionality of managing jobs. Also, notice that INGEST execution time is about HALF of IMPORT execution time, without the
limitations of the LOAD command.
5.6 LOAD utility

The LOAD utility is best suited to situations where performance is your primary concern. It is much faster than the IMPORT utility
because it writes formatted pages directly into the database rather than using SQL INSERTS. The load utility also allows you
the option of not logging the transactions. Load operations can fully exploit resources such as memory and multiple processors.
The LOAD, like the EXPORT and IMPORT utilities, is cross-platform compatible. This utility can be used as an alternative to the
IMPORT utility. Use the LOAD utility if you want to move large quantities of data into empty tables or tables that already contain
data.

IBM Software
The following parameters impact the LOAD utility's performance.
SAVECOUNT n
DATA BUFFER buffer – size
SORT BUFFER buffer - size
CPU_PARALLELISM n
DISK_PARALLELISM
FETCH_PARALLELISM
INDEXING MODE
REBUILD
INCREMENTAL
AUTOSELECT
DEFERRED
ALLOW NO|READ ACCESS
LOCK WITH FORCE
If a value is not specified for DATA BUFFER, CPU_PARALLELISM, or DISK_PARALLELISM, an intelligent default is calculated
by the utility at run time.
As shown in Figure 18, the record order in the source data can be preserved when CPU_PARALLELISM is set to allow multiple
processes or threads.
Figure 19 – LOAD source data order preserved
During the development of this lab we were not able to capture much information with the LOAD QUERY command because our
table is small and the LOAD completes very quickly. You can try if you like with the following loop, or you can skip this set of
commands. If you want to try, open a new terminal session and enter these commands to monitor the progress of the LOAD
operation. Press Enter after each line.

IBM Software

while true
do
sleep 2
echo -e "\n## New Load Query ##"
db2 load query table reldata | tee -a loadQuery.txt
done
Switch to an unused terminal session. Delete the data in the table and verify the records have been deleted with the following
commands.

db2 truncate table reldata reuse storage immediate
Start the LOAD and verify the records were loaded with the following commands. The LOAD command should be entered on a
single line.
cd /tmp/db2move
db2 load from tab1.ixf of ixf savecount 50 messages load.msg insert into
reldata cpu_parallelism 2
db2 connect reset
If you tried to monitor the LOAD progress with the loop, switch back to that terminal session and press Ctrl+C to cancel the loop.
You can review the output of the command in file loadQuery.txt. Note: you may have to repeat the load a couple of times for the
query to show results since it is such a small load.
6 Further maintenance utility discussions

DB2 provides other utilities for moving data. These include stored procedures such as ADMIN_COPY_SCHEMA,
ADMIN_MOVE_TABLE and ADMIN_MOVE_TABLE_UTIL, DB2 system commands such as db2relocatedb and several
administrative APIs.
If you require 24x7 availability then you will probably implement a form of high availability for your database. It is possible to
eliminate some maintenance activity against a primary production server by applying maintenance to the standby, or backup
server.
Many companies and organizations have established Service Level Agreements or SLAs. These formalized requirements will
have a significant bearing on how you will configure your DB2 system and commands, often requiring you to trade availability for
performance.

IBM Software
7 Cleanup
db2 connect reset

db2 force application all
db2 terminate
db2 deactivate db xmldb
db2 drop db xmldb
db2stop
rm -rf ~/sqllib/db2dump/*
rm -rf /backup/*
rm -rf /archive/*
rm -rf /logs/*
rm -rf /tmp/restore/*
rm -rf /tmp/db2move/*

IBM Software

IBM Canada
8200 Warden Avenue
Markham, ON
L6G 1C7
Canada


IBM operates.

objectives only.


they are provided.


DB2-V10 PerfClinic Workbook v20120706

Uploaded by

Document Information

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-V10 PerfClinic Workbook v20120706

Uploaded by

Copyright:

Available Formats

IBM Software

DB2® 10 for LUW Performance Tuning and

DB2 PERFORMANCE MONITORING & TUNING INTRO ............................. 3

DB2 ESSENTIAL PERFORMANCE & MONITORING ................................... 26

DB2 SQL QUERY TUNING ............................................................................ 128

DB2 PERFORMANCE CLINIC – LOCKING................................................... 190

DB2 PERFORMANCE CLINIC – LOGGING .................................................. 209

DB2 MAINTENANCE UTILITIES & PERFORMANCE................................... 222

DB2 Performance Tuning and Monitoring Clinic Workbook page 2 of 251.

DB2® Performance Tuning & Monitoring Intro

DB2 Performance Tuning and Monitoring Clinic Workbook page 3 of 251.

5 Database Creation Best Practices and Exercises ..........................................................................................................................10

6 Collecting Baseline Information .......................................................................................................................................................19

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 4 of 251.

2 About this Lab

4 Environment Requirements and Setup

4.1 Unpacking the image

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 5 of 251.

4.2 Preparation Step

Figure 1 – Opening a VMware Image File

4.3 Start the Virtual Machine

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 6 of 251.

Figure 2 – Start the Virtual Machine

in the toolbar on top of the VMware window.

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 7 of 251.

Figure 3 – Linux Distribution Statement

Figure 4 – SUSE Linux Enterprise Server License Agreement

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 8 of 251.

Figure 5 – VMware Tools License Agreement

Figure 6 – DB2 V10 License Agreement

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 9 of 251.

Figure 7 – DB2 V10 Trial Version Notice

Figure 8 – License Agreements

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 10 of 251.

At the login prompt, login with the following credentials:

Figure 9 – Login credentials

4.5 Open the Terminal Window

Figure 10 – Opening a Terminal

2. Start the Database Manager as follows:

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 11 of 251.

Attention: You need to type a space between the two dots.

5 Database Creation Best Practices and Exercises

• Automatic statistics collection being enabled

• Adaptive Self Tuning Memory being enabled

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 12 of 251.

5.1 Create customized database

db2 "create database INTRO ON /data1, /data2 DBPATH ON /home/db2inst1

db2 get db cfg for intro |grep -i "path to log"

DB2 Performance Clinic Lab

DB2 Performance Tuning and Monitoring Clinic Workbook page 13 of 251.

Changed path to log files (NEWLOGPATH) =

DB2 Object Location

Database configuration file home/db2inst1/db2inst1/NODE0000/SQL00001

• buffer pool information

db2 "update db cfg for intro using NEWLOGPATH /logs"