Professional Documents
Culture Documents
Whei-Jen Chen
Bill Comeau
Tomoko Ichikawa
S Sadish Kumar
Marcia Miskimen
H T Morgan
Larry Pay
Tapio Vttnen
ibm.com/redbooks
SG24-7524-00
Note: Before using this information and the product it supports, read the information in
Notices on page vii.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Workload management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 DB2 Workload Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chapter 2. Workload Manager architecture and features . . . . . . . . . . . . . . 7
2.1 DB2 Workload Manager concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 DB2 service classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 DB2 workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 DB2 thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.4 Work class sets and work action sets . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 DB2 WLM monitor and control capabilities . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1 Real-time monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.2 Statistics table functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.3 Event monitors for DB2 WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.4 WLM stored procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 New database configuration parameter and catalog tables . . . . . . . . . . . 31
2.5 Working with WLM SQL and objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5.1 DB2 Service classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5.2 DB2 Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5.3 DB2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.4 DB2 Work Classes and Work Class Sets . . . . . . . . . . . . . . . . . . . . . 37
2.5.5 DB2 Work Actions and Work Action Sets . . . . . . . . . . . . . . . . . . . . . 39
2.6 DB2 WLM setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6.1 Lab environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.6.2 First step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
iii
iv
6.2.3 Integrating DB2 service classes with AIX service classes . . . . . . . 156
6.2.4 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Chapter 7. WLM sample scenarios - other usage . . . . . . . . . . . . . . . . . . 173
7.1 Capacity planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
7.1.1 The workload environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
7.1.2 Collecting the trending data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.1.3 Monitoring and analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.1.4 Capacity planning - summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
7.2 Chargeback accounting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
7.2.1 Business objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
7.2.2 Defining workload profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
7.2.3 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
7.2.4 Chargeback accounting - summary . . . . . . . . . . . . . . . . . . . . . . . . 186
Chapter 8. DWE Design Studio and DB2 WLM . . . . . . . . . . . . . . . . . . . . . 187
8.1 DB2 Warehouse Design Studio overview . . . . . . . . . . . . . . . . . . . . . . . . 188
8.1.1 Workload management support . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
8.2 Getting started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
8.2.1 Workload Management Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.3 Managing database workloads using Design Studio. . . . . . . . . . . . . . . . 197
8.3.1 Create workload scheme by objective . . . . . . . . . . . . . . . . . . . . . . 199
8.3.2 Create workload scheme by yourself . . . . . . . . . . . . . . . . . . . . . . . 240
8.3.3 Create workload scheme by reverse engineering . . . . . . . . . . . . . . 243
8.4 Execute a workload management scheme . . . . . . . . . . . . . . . . . . . . . . . 248
8.5 AIX WLM management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
8.5.1 Creating operating system service classes and limits. . . . . . . . . . . 255
8.5.2 Configure AIX WLM using Design Studio . . . . . . . . . . . . . . . . . . . . 263
Chapter 9. DB2 Workload Manager and DB2 Performance Expert . . . . . 271
9.1 DB2 Performance Expert overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
9.2 Monitoring your DB2 environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
9.2.1 Monitoring instance and database statistics . . . . . . . . . . . . . . . . . . 278
9.3 Monitoring DB2 Workload Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
9.3.1 Workload Management Key Performance Indicators . . . . . . . . . . . 282
9.3.2 Viewing workload management definitions . . . . . . . . . . . . . . . . . . . 283
9.3.3 Viewing Workload Management statistics. . . . . . . . . . . . . . . . . . . . 287
Contents
vi
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
vii
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. These and other IBM trademarked
terms are marked on their first occurrence in this information with the appropriate symbol ( or ),
indicating US 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 http://www.ibm.com/legal/copytrade/shtml.
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX 5L
AIX
DB2
IBM
Redbooks
Redbooks (logo)
WebSphere
viii
Preface
DB2 Workload Manager (WLM) introduces a significant evolution in the
capabilities available to database administrators for controlling and monitoring
executing work within DB2. This new WLM technology is directly incorporated
into the DB2 engine infrastructure to allow handling higher volumes with minimal
overhead. It is also enabled for tighter integration with external workload
management products, such as those that are provided by AIX WLM.
This IBM Redbooks publication discusses the features and functions of DB2
Workload Manager for Linux, UNIX, and Windows. It describes DB2 WLM
architecture, components, and the WLM-specific SQL statements. It
demonstrates installation, WLM methodology for customizing the DB2 WLM
environment, new workload monitoring table functions, event monitors, and
stored procedures. It also provides examples and scenarios using DB2 WLM to
manage database activities in DSS and OLTP mixed database systems.
Through the use of examples, you will learn about these advanced workload
management capabilities, and see how they can be used to explicitly allocate
CPU priority, detect and prevent runaway queries, and to closely monitor
database activity in a number of different ways.
The book also discusses using Data Warehouse Edition Design Studio and DB2
Performance Expert with DB2 WLM. Finally, the primary differences between
Workload Manager and Query Patroller are explained, along with how they
interact in DB2 9.5.
ix
Solaris, and Linux. Before joining IBM in 1999, he worked as a DBA and
Systems Analyst for 15 years, implementing and supporting multiple databases
for several large companies in California. Larrys area of expertise is the
implementation, support, and performance tuning of DB2 UDB data warehouses.
Tapio Vttnen is an IT Specialist with IBM Global Technology Services in
Finland. He has more than 12 years of experience in the IT industry, and has
spent almost half of his career as a UNIX Specialist, working on databases in
UNIX and Linux environments. Tapio is an IBM Certified DB2 Administrator and
is currently working on the Finnish DB2 team, providing consultation services
and supporting DB2 customers focusing on high availability, performance tuning
and disaster recovery solutions.
Figure 1 Left to right: Larry, Tapio, H T, Tomoko, Sadish, and Marcia. Bill Comeau (not
shown) also participated in this project.
Acknowledgements
The authors express their deep gratitude for the advice and support they
received from Paul Bird at the IBM Toronto Laboratory.
We also thank the following people for their support and contributions to this
project:
Karen Mcculloch
Louise McNicoll
Mokhtar Kandil
Francis Wong
IBM Toronto Laboratory
Preface
xi
Kevin Beck
Dinkar Rao
Elizabeth Benavidez
IBM Software Group, USA
Tetsuya Shirai
IBM Systems Engineering, Japan
Anne Lesell
IBM Global Business Services, Finland
Nela Krawez
Ute Baumbach
Torsten Steinbach
IBM Software Group, Germany
Many thanks to our support staff for their help in the preparation of this book:
Emma Jacobs, Sangam Racherla, and Deanna Polm
International Technical Support Organization, San Jose Center
Comments welcome
Your comments are important to us!
xii
Preface
xiii
xiv
Chapter 1.
Introduction
In today's world, data is being collected faster than at any other period in history.
At the same time many businesses are trying to maximize their cost efficiencies
by using their computing hardware and software resources as heavily as
possible. Data servers are being consolidated, report generation is easily
accessible, and users are permitted ad hoc access to valuable data. This trend
leads to increased potential for periodic chaos in any data server environment.
Thus, methods are needed for returning stability, predictability, and control (in
the form of resource and request management and monitoring) back to data
server customers in the form of workload management.
DB2 Workload Manager (WLM), integrated into the DB2 9.5 data server for
Linux, UNIX, and Windows, is a comprehensive workload management feature
that gives you deeper insight into how your system is running, and finer control
over resources and performance.
By reading this book, you will become familiar with the enhanced workload
management capabilities that are included in the DB2 Version 9.5 release.
We discuss the following topics in this chapter:
The background of workload management
Concepts of workload management
DB2 Workload Manager
Chapter 1. Introduction
Protecting the data server from a system slowdown during peak periods of
database activity
Normally there are periods during every day (or week, or month) where a
large number of database activities seem to all be executing at the same
time. Not surprisingly, this often results in resource contention and slowdowns
on the system.
Providing explicit resource control
Resource allocation and resource contention can be a real problem on the
data server machine. Customers need ways to fairly allocate resources
across execution environments and limit excess resource consumption.
Enforcing Service Level Agreement (SLA) objectives
Service Level Agreements often introduce explicit response time goals for
database activities, with few or no methods in place to control the workloads
and use monitor information to cheaply determine how the data server is
tracking to those goals.
Granular monitoring of database activities (that is, the ability to monitor the
whole life cycle of activities, as well as the aggregate distribution)
Often a big picture view of data server activity is sufficient information to
determine the overall health of the activity distribution. Sometimes detailed
information is required for problem determination and historical analysis.
In the following chapters you will learn, in detail, how DB2 workload management
can be used to address these business problems. You will also gain insight into
the DB2 workload management concepts and architecture, how to get started
using WLM with samples and best practices, as well as tool integration and
problem determination suggestions.
Chapter 1. Introduction
Chapter 2.
Workload Manager
architecture and features
In this chapter we describe the DB2 9.5 Workload Manager (WLM) architecture
and components, and explain how they interrelate with each other. The role of
each major WLM component is discussed from a business point of view, and
what part it plays in the WLM architecture is also examined.
Prior to DB2 V9.5, workload management meant the use of DB2 Query Patroller
in conjunction with the DB2 Governor. In DB2 9.5, workload management means
the use of DB2 Workload Manager by itself, in conjunction with the DB2
Governor, or coexisting with the DB2 Query Patroller and the DB2 Governor.
We discuss the following topics in this chapter:
Service classes
Workloads
Thresholds
Work action sets and Work classes sets
The DB2 WLM architecture revolves around defining execution environments for
activities, and assigning resources to those execution environments.The DB2 9.5
implementation starts with CPU and I/O resource management for DB2
workloads, including asking how can resource sharing be done effectively, as
well as how is this resource sharing used to ensure stability to cope with changes
in priority and fluctuating loads on the system.
Because the service class is the primary point for resource assignment to all
incoming database requests and is used for monitoring database activities, we
recommend that you identify service classes based on your critical business
10
requirements. For example, you can set up service classes based on any of the
following criteria:
Service level agreements (SLAs)
Need for very high-priority work to bypass normal work queue
Conflict in sharing the same CPU and I/O resources
Clearly defined logical work groupings
Users or departments consistently exceeding resource constraints to the
detriment of other users or departments
Need to identify and analyze work contributing to resource peak usage
Need to validate and plan for data server capacity
A DB2 service subclass can belong to only one DB2 service superclass, but a
DB2 service superclass can have one or more DB2 service subclasses. The
maximum number of service superclasses that can be created for a database is
64. The maximum number of service subclasses that can be created under a
superclass is 61.
You can create a DB2 service superclass using the CREATE SERVICE CLASS
statement. Example 2-1 displays the SQL statements to create service
superclasses and service subclasses that are shown in Figure 2-1 on page 10.
Example 2-1 Create service superclasses
------------------------------------------------------------ Create service superclasses
----------------------------------------------------------CREATE SERVICE CLASS sales;
CREATE SERVICE CLASS finance;
CREATE SERVICE CLASS marketing;
------------------------------------------------------------ Create service sub classes
----------------------------------------------------------CREATE SERVICE CLASS directsales UNDER sales;
CREATE SERVICE CLASS channelsales UNDER sales;
CREATE SERVICE CLASS accounting UNDER finance;
CREATE SERVICE CLASS promotions UNDER marketing;
In DB2 9.5 on AIX, DB2 workload management can be tightly integrated with the
AIX Workload Manager such that the AIX Workload Manager can be used to
control CPU shares for database work through the use of AIX service classes.
This integration is discussed in more detail in Chapter 6, AIX Workload Manager
considerations on page 143.
11
12
Example 2-3 shows the SQL code to define the CAMPAIGN and
NEWCAMPAIGN workloads.
13
14
limit the number of connections, the elapsed time, the amount of tempspace
used, and the estimated SQL cost of an activity.
There are two types of DB2 WLM thresholds:
Activity thresholds: This threshold applies to an individual activity. When the
resource usage of an individual activity violates the activity threshold, it
triggers the threshold, which is applied only once.
Aggregate threshold: This threshold sets a limit on a measurement across a
set of multiple activities and operates as a running total, to which any work
tracked by the threshold contributes.
The supported actions for a threshold are:
STOP EXECUTION
Stop processing the activity that caused the threshold to be exceeded. For a
threshold with a built-in queue, it means reject any newly arriving work from
joining the queue.
CONTINUE
Do not stop processing an activity if the threshold is exceeded. For a
threshold with a built-in queue, it means add any newly arriving work to the
queue.
COLLECT ACTIVITY DATA
You can collect information about the activity that exceeded the threshold
with different degrees of detail.
Figure 2-3 illustrates a threshold created to control database activities. In this
example, when a new product is launched, the entire Sales department may
want to access the database. The Sales department wants to restrict the number
of connections to 20 so that database performance is not affected by the surge in
interest. This can be done by defining a threshold for service class SALES,
setting the maximum number of concurrent database connections on a
coordinator partition to 20, and setting the maximum number of queued
connections to 5. If these limits are exceeded, the application will be stopped.
15
16
Database
Service superclass
Service subclass
Work action
Workload
In each of these threshold domains, the threshold can be enforced over a single
workload occurrence, a database partition, or across all the partitions of the
database. This is known as the enforcement scope of the threshold. The
enforcement scope can therefore be a workload occurrence, a database
partition, or the entire database (also known as a global enforcement scope).
Figure 2-4 shows a summary of the DB2 WLM thresholds and the scope and
domain that each threshold applies to.
When multiple activity thresholds apply to one activity, you must decide which
threshold to enforce and in what order. To resolve the scope of activity threshold
resolution, WLM observes a hierarchy of domains so that a value defined in a
local domain overrides a value from a wider or more global domain. We follow
the hierarchy of domains for these activity thresholds, numbered in the order in
which threshold enforcement occurs:
1.
2.
3.
4.
5.
Workload
Service subclass
Service superclass
Work Action
Database
Some thresholds, known as queueing thresholds, have a built-in queue and are
defined with two boundaries: a threshold boundary and a queueing boundary.
17
Work actions are grouped into work action sets. A work action can apply to either
activities at the database level, or to activities at the service superclass level
18
depending on the object that the work action set containing the work action is
applied to.
To create a work action set and a work action, use the CREATE WORK ACTION
SET statement. You must do the following:
Associate the work action set with an existing work class set, and associate
the work action with an existing work class within the same work class set that
the work action set was associated with.
Associate the work action set with either the database or an existing
user-defined service superclass.
A work action set may be applied to an incoming database request, but more
than one work action may be applied by the work action set. In such a case, the
first matching work action in an ordered list will be applied. The position of the
work action in the ordered list can be changed, depending on which work action
needs to be given priority.
The following actions can be performed within a DB2 work action set:
Count activity
Prevent execution of an activity
Collect activity data
Map work to a different service sub class within the same superclass
Apply a threshold to an activity that falls within the work class the work action
is applied to, if the work action set is applied at the database level.
Collect aggregate activity data for activities associated with the work class for
which this work action is defined, when the work action set that the work
action is in, is applied to a service superclass.
Figure 2-5 illustrates using work class sets and work action sets to manage
workloads. In this example, there are two goals desired. The first goal is to stop
expensive queries costing 1000001 timerons or more, and the second goal is to
gather more information about stored procedures running in the SALES service
superclass.
To achieve these goals, work class sets must first be created. A work class set
named CLASSIFY_QRY is associated with the work class LARGE_QRY having
a work type of READ. A work action set called DBACTIONS is associated with
the database, and the work action STOP_LARGE_QRY is associated with the
work class LARGE_QRY. When an incoming database request of work type
READ with a timeron cost greater or equal to 1000001 is encountered, the
execution of this database request is stopped, and data about this request is
collected for analysis.
19
Example 2-4 shows the definitions of work class set and work action set.
Example 2-4 Defining a work class set
CREATE SERVICE CLASS PROBLEM_SP_SC UNDER SALES COLLECT ACTIVITY DATA ON
COORDINATOR WITH DETAILS
CREATE WORK CLASS SET CLASSIFY_QRY (WORK CLASS LARGE_QRY WORK TYPE READ FOR
TIMERONCOST FROM 1000001 To UNBOUNDED)
CREATE WORK ACTION SET DBACTIONS FOR DATABASE USING WORK CLASS SET CLASSIFY_QRY
(WORK ACTION STOP_LARGE_QRY ON WORK CLASS LARGE_QRY
WHEN ESTIMATEDSQLCOST > 1000001 COLLECT ACTIVITY DATA STOP EXECUTION)
CREATE WORK CLASS SET PROBLEM_SP_WCS (WORK CLASS CALLSTATEMENTS WORK TYPE CALL
ROUTINES IN SCHEMA "SALES")
20
2.2 Architecture
The architecture of the DB2 Workload Manager integrates all the workload
management objects into a coherent whole in order to make it easier to identify,
manage, and monitor all workload in the DB2 database. The workload on the
system can be analyzed to determine how the system can be designed to cope
with the current and anticipated workload.
Performance monitoring using DB2 WLM can track the behavior of the system,
either on a granular level or over a wide-ranging period. The principal benefit,
however, is the ability to understand the characteristics of the incoming
workload. That knowledge will enable you to manage and maintain the system
desired response times and throughput. In addition, some of the most vexing
problems in a database environment, such as runaway or rogue queries and
agent contention, can be handled more effectively with the new WLM
capabilities.
The process of using DB2 WLM effectively starts with analyzing the workload by
identifying the types and frequency of workloads, and then creating service
classes in order to classify the workload into manageable groups.
The diagram in Figure 2-6 illustrates the interrelationships of the main
components of the DB2 WLM architecture.
21
22
A threshold
PREVENT EXECUTION
COLLECT ACTIVITY DATA
COUNT ACTIVITY
Work actions 2A and 2B belong to work action set 2, and they are defined for
service superclass 2. The work actions 2A and 2B can be any of the following
actions:
A mapping action mapping an activity to any service subclass in service
superclass 2 except for the default service subclass.
PREVENT EXECUTION
COLLECT ACTIVITY DATA
COLLECT AGGREGATE ACTIVITY DATA
COUNT ACTIVITY
Users assigned to workload D are mapped to a service superclass 3, which does
not have a user-defined service subclass. In this case, the connections are
mapped to the default subclass SYSDEFAULTSUBCLASS of service
superclass 3.
Connections that do not map to a user-defined workload are mapped to the
default workload SYSDEFAULTUSERWORKLOAD, and this in turn is mapped
to the default service superclass for user requests, SYSDEFAULTUSERCLASS.
Internal DB2 system connections are mapped to the default service superclass
for internal DB2 connections, SYSDEFAULTSYSTEMCLASS. Internal DB2
maintenance connections are mapped to the default service superclass for
maintenance requests, SYSDEFAULTMAINTENANCECLASS.
As illustrated in Figure 2-6, DB2 WLM thresholds (indicated by
defined on any or all of the following:
) can be
Database
Work action set
Service superclass
Service subclass
Workload
If the DB2 environment is on AIX, and the AIX WLM is being used, it is possible
to associate the DB2 service classes with their corresponding AIX service
classes as illustrated in Figure 2-7. The DB2 service classes are associated with
their corresponding AIX service classes by using the OUTBOUND
CORRELATOR keyword in the CREATE SERVICE CLASS statement to
associate threads from the DB2 service class to an AIX service class.
23
In Figure 2-7:
DB2 service superclasses 1 and 2 are associated with AIX WLM service
classes _DB2_SUPERCLASS 1 and _DB2_SUPERCLASS 2, respectively.
DB2 service subclasses 1A, 2A and 2B are associated with AIX WLM
subclasses _DB2_SUBCLASS 1A, _DB2_SUBCLASS 2A and
_DB2_SUBCLASS_2B, respectively.
DB2 service class SYSDEFAULTUSERCLASS is associated with AIX WLM
service class _DB2_DEF_USER.
DB2 SERVICE classes SYSDEFAULTSYSTEMCLASS and
SYSDEFAULTMAINTENANCECLASS are associated with AIX WLM service
class _DB2_DEF_SYS.
We discuss the relationship between AIX WLM and DB2 WLM in more detail in
Chapter 6, AIX Workload Manager considerations on page 143.
The following lists shows all the WLM-exclusive SQL that can be used to set up
and manage WLM:
CREATE WORKLOAD, ALTER WORKLOAD, DROP WORKLOAD
GRANT (Workload Privileges), REVOKE (Workload Privileges)
CREATE SERVICE CLASS, ALTER SERVICE CLASS, DROP SERVICE
CLASS
24
CREATE WORK CLASS SET, ALTER WORK CLASS SET, DROP WORK
CLASS SET
CREATE WORK ACTION SET, ALTER WORK ACTION SET, DROP WORK
ACTION SET
CREATE THRESHOLD, ALTER THRESHOLD, DROP THRESHOLD
CREATE HISTOGRAM TEMPLATE, ALTER HISTOGRAM TEMPLATE,
DROP HISTOGRAM TEMPLATE
We discuss the SQL statements in more detail in 2.5, Working with WLM SQL
and objects on page 32.
In creating the WLM objects and the SQL to generate it, use the DWE Design to
help generate SQL and rules validation for WLM. A section on how to use this
tool is discussed in 8.1, DB2 Warehouse Design Studio overview on page 188.
25
WLM_GET_SERVICE_CLASS_AGENTS
This table function returns a list of database agents associated with a service
class or application handle, the current state of the agent, the action the agent
is performing and the status of that action.
WML_GET_WORKLOAD_OCCURRENCE_ACTIVITIES
This table function returns a list of current activities associated with a
workload occurrence, information about the activity, the type of activity and
the time the activity started.
WLM_GET_ACTIVITY_DETAILS
This table function returns detail about an individual activity, the activity type,
and additional information pertinent to that activity type.
26
The workload management table functions can also be used in conjunction with
the snapshot monitor table functions to aid in problem-solving or performance
tuning.
27
Service superclasses:
Top concurrent connection
Workloads:
The following statistics are collected for each database partition for the
corresponding service class or work class when a service subclass or a work
28
The following statistics are collected for each database partition for the
corresponding service subclass when a service subclass or a work class is
created or altered with the option COLLECT AGGREGATE REQUEST DATA
BASE:
Request execution time average
Request execution time histogram
Histogram
A histogram is defined as a graphical display of tabulated frequencies. In DB2
WLM, the histogram is represented by a collection of bins or rectangles where
the width is represented by a range of values, and the height is represented by
the count or frequency of these values. DB2 WLM histograms have a fixed
number of 41 bins. Figure 2-8 shows a histogram example.
29
30
WLM_COLLECT_INT
This new database configuration parameter WLM Collection Interval is used to
specify a collection and reset interval, in minutes, for workload management
statistics. This parameter is only specified on the catalog partition, and it will
determine how often workload management statistics are collected and sent to
any statistics event monitor. All WLM statistics table functions will return the
accumulated statistics for the current interval since the last reset. The
WLM_COLLECT_STATS procedure will perform the same collect and reset
operations that would occur automatically on the interval defined by the
WLM_COLLECT_INT database configuration parameter.
31
32
33
SESSION_USER
If you use the SET SESSION AUTHORIZATION statement to change the
current session user, you can use this attribute. If you do not use the SET
SESSION AUTHORIZATION statement, the current session user is the same
as the system user.
If you use a customized security plug-in for authentication, you can return a
different value for the current session user.
SESSION_USER GROUP
You can use the group name which the current session user belongs to.
SESSION_USER ROLE
If you use the roles to simplify privilege management, you can use this
attribute.
CURRENT CLIENT_USERID
You can use the client user ID from the client information specified for the
connection.
CURRENT CLIENT_APPLNAME
You can use the application name from the client information specified for the
connection.
CURRENT CLIENT_WRKSTNNAME
You can use the workstation name from the client information specified for the
connection.
CURRENT CLIENT_ACCTNG
You can use the accounting string from the client information specified for the
connection. The accounting string basically is a custom tag that can be used
to identify a set of activities based on user-defined attributes such as a
custom report.
Users can connect directly, or through an application server with different
connection properties to DB2. DB2 WLM uses these properties to direct them to
the appropriate service class.
In an N-tier client-server environment, an application server can use the sqlseti
API, where client information is set on the client side, to pass specific client
information to the DB2 data server.
Another way to set client information is to use the WLM_SET_CLIENT stored
procedure to set client information for the connection at the DB2 server.
34
35
Threshold domain
DATABASE / SERVICE CLASS / WORKLOAD
Enforcement scope
DATABASE / DATABASE PARTITION / WORKLOAD OCCURRENCE
Threshold
Elapsed time (ACTIVITYTOTALTIME)
The maximum amount of time that the data server should spend
processing an activity.
Idle time (CONNECTIONIDLETIME)
The maximum amount of time that a connection can be idle.
Estimated cost (ESTIMATEDSQLCOST)
The maximum estimated cost permitted for DML .
Rows returned (SQLROWSRETURNED)
The maximum number of rows that can be returned for DML.
Temporary space (SQLTEMPSPACE)
The maximum amount of temporary table space that can be used by a
DML activity at any database partition.
Concurrent workload occurrences
(CONCURRENTWORKLOADOCCURRENCES)
The maximum number of workload occurrences that can run concurrently
on the coordinator partition.
Concurrent workload activities (CONCURRENTWORKLOADACTIVITIES)
The maximum number of coordinator and nested activities that can run
concurrently in a workload occurrence.
Concurrent database activities (CONCURRENTDBCOORDACTIVITIES)
The maximum number of concurrent coordinator activities across all
database partitions.
Total database partition connections
(TOTALDBPARTITIONCONNECTIONS)
The maximum number of concurrent database connections on a
coordinator partition for a database.
Total service class partition connections
(TOTALSCPARTITIONCONNECTIONS)
The maximum number of concurrent database connections on a
coordinator partition for a service superclass.
36
Action
STOP EXECUTION / CONTINUE
Optionally, you can specify the following properties:
Action
COLLECT ACTIVITY DATA clause
Use this clause to enable collection of information about activities that violate
the threshold. Activity information is sent to the active activities event monitor
upon activity completion.
ENABLE or DISABLE
Use this clause to specify whether or not the threshold is enabled for use by
the database manager.
Example 2-8 shows the CREATE THRESHOLD statement to create a threshold
assigned to a service subclass.
Example 2-8 Creating a threshold
CREATE THRESHOLD limit_cost for SERVICE CLASS sales ACTIVITIES ENFORCEMENT
database WHEN estimatedsqlcost > 10000 STOP EXECUTION
The threshold (when estimatedsqlcost > 10000) is enforced for activity that runs
in the department superclass across all database partitions.
37
command, all the statements in Table 2-1 are intercepted immediately before
execution.
Table 2-1 Work type keywords and associated SQL statements
Work type
keyword
READ
WRITE
CALL
CALL statement
The CALL statement is only classified under the CALL and ALL
work class types.
DML
All statements that are classified under the READ and WRITE work class
types
DDL
LOAD
Load utility.
The load utility is only classified under the LOAD and ALL work
class types.
ALL
Example 2-9 shows the CREATE WORK CLASS SET statement to create a work
class READ_WORK and a work class WRITE_WORK.
38
39
40
Clyde
CPU
CPU
Bonnie
CPU
CPU
CPU
CPU
RAM
CPU
RAM
OS DISK
/db2data
CPU
OS DISK
NFS mount
/db2home
/db2data
/db2logs /db2alogs
/db2logs /db2alogs
External SAN
41
Figure 2-10 illustrates the partition configuration of the WLMDB database that we
created on the AIX systems. WLMDB spreads over two physical nodes, and it
consists of five database partitions. Partition 0 on Clyde acts as the coordinating
partition. WLMDB has six database partition groups:
IBMCATGROUP for system catalogs on partition0, the coordinating partition.
IBMDEFAULTGROUP spans all five partitions. This has only one table
space, USERSPACE1, which is the default table space for new tables. Our
intention is not to use this table space for our tests.
IBMTEMPGROUP spans all partitions. This has only one table space, which
is for temporary tables.
NG1 is in partition 0 only. NG1 contains one table space for small referencing
tables.
NG2 spreads over database partition 1 to partition 4. This partition group has
table spaces for our data for tests and benchmarking.
NGALL spans all database partitions. It has only one table space, MAINT, for
event monitor data to be used for historical analyses.
Clyde
Partition 0
Bonnie
Partition 1
IBMCATGROUP
Partition 2
Partition 3
NG2
SYSCATSPACE1
LINED
SYSTOOLSPSACE
LINEI
SYSTOOLSTMPSPACE
ORDERSD
ORDERSI
NG1
SMALL
OTHERS
TWORK
NGALL
MAINT
IBMDEFAULTGROUP
USERSPACE1
IBMTEMPGROUP
DB2TMP16K
42
Partition 4
TPC-H
We deploy TPC-H data for our test database. You can find more information
about TPC-H at the following address:
http://www.tpc.org/tpch/
= DB2/AIX64 9.5.0
= DB2INST1
= WLMDB
WORKLOADNAME
-----------------------SYSDEFAULTUSERWORKLOAD
SYSDEFAULTADMWORKLOAD
2 record(s) selected.
43
User Requests
Default
User
workload
Admin Requests
Default
Admin
workload
Default Subclass
Default Subclass
44
45
that the highest concurrent number of connections was 4 and that the total
number of completed connections was 197 for workload
SYSDEFAULTUSERWORKLOAD, since the last reset.
By looking at this information and the service subclasses statistics (shown in
Example 2-12) over time, you can achieve a useful understanding of your
database system load.
Example 2-13 Summary statistics at the workload level
SELECT CONCURRENT_WLO_TOP,
COORD_ACT_COMPLETED_TOTAL
FROM TABLE(WLM_GET_WORKLOAD_STATS('SYSDEFAULTUSERWORKLOAD',-2));
CONCURRENT_WLO_TOP COORD_ACT_COMPLETED_TOTAL
------------------ ------------------------4
197
1 record(s) selected.
Use the workload occurrences function to examine the connections on the
system. In particular, use this function to understand who is submitting work
into system (that is, which users or which applications), and also to learn
about the connection attributes for the applications that submit work to the
system. This information is particularly useful if you want to isolate those
applications.
Example 2-14 shows how to list the workload occurrences on a particular
service class by using the WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES
table function.
Example 2-14 List of workload occurrences on a particular service class
APPLICATION_NAME
---------------SAP.EXE
OLTP.EXE
BATCH.EXE
3 record(s) selected
46
Use the workload activities table function to understand the types of activities
that are run on the system. For example, you could periodically run a query
that counts number of activities of a specific type. Over time, you would build
up an understanding of the number of loads, the number of reads, and so on.
Example 2-15 shows using the WLM_GET_WORKLOAD_OCCURRENCE_ACTIVITIES
table function to list queries and query types running on the system. We see
that there are currently two reading activities and one writing activity. By
collecting this information periodically over a time frame, you can learn how
activity types and the quantity of each activity differ over time.
Example 2-15 List queries and query types running on the system
47
'ACTIVITY_ID',
'ACTIVITY_TYPE',
'EFFECTIVE_ISOLATION',
'ROWS_FETCHED',
'ROWS_MODIFIED');
NAME
-------------------ACTIVITY_ID
ACTIVITY_TYPE
APPLICATION_HANDLE
LOCAL_START_TIME
UOW_ID
EFFECTIVE_ISOLATION
ROWS_FETCHED
ROWS_MODIFIED
VALUE
-----------------------------1
WRITE_DML
420
2007-11-14-04.43.00.004358
10
1
6
21
8 record(s) selected.
48
Chapter 3.
49
50
51
often available at the very beginning of the planning process and is based on
business requirements:
What are the business requirements?
Are there Service Level Agreements (SLAs) that must be met?
Are there management or user requirements?
Using this information, first develop a comprehensive view of the work in the
database that needs to satisfy these business requirements. Next, identify the
characteristics and changes to the workload by using workload profiling.
Checklist
In the process of identifying the workload, gather as much as information about it
as possible. In the management stage, this information will be used to customize
the WLM to manage your workload to meet the business goal. Here we list the
items to be identified:
Tasks
What processes do you want to identify, or what you have discovered from
previous monitoring?
Examples of processes to identify include utilities run by DBA, all the report
jobs, and so on.
Business requirements
What is the purpose or function of a task? What requirements are attached to
this task?
These requirements should be expressed in terms of desired outcome, such
as an SLA or business restrictions.
Task identity
How is the process identified in the system?
WLM will identify what workload comes to the database system; it can identify
a process or workload by using the following:
For each task, you must identify at least one of these for WLM.
52
Action
What action is needed for this process? What do you want to happen to
control or measure this task?
WLM provides the following actions:
Database level data collection
Detailed data collection (at all levels: database, service class, workload
The information about each activity that executes in the service class
will be sent to the applicable event monitor when the activity
completes. The SQL statement clause is:
COLLECT ACTIVITY DATA
Controls on processes
You specify what to control and the control scope by using WORK ACTION or
THRESHOLD.
53
Business requirements
Identification
Action
Admin
groupid = DB2ADM
Batch
54
Task
Business requirements
Identification
Action
Production
groupid = dssgroup
_Analysis Reports
exec = dss.exe
55
Workload
To assign the task activities for each service classes, we create workloads
using Identification.
Event monitor
To collect and store aggregate information in tables, we create a
write-to-table statistics event monitor.
In our basic setup, we want to create historical analysis reports.
56
Example 3-1 shows service classes DML. We chose to use aggregate levels of
collection, COLLECT AGGREGATE ACTIVITY DATA BASE. This level of data collection
has the least impact on the system, and presents a high level of information in
our monitoring.
Additionally, we want both aggregate activity and aggregate request data, but not
for the level for all service classes. The type of collection depends on the type of
data to be collected. The WLM documentation explains each type of data
collection. It is recommended that you collect only the data that will be used to
monitor and report on the workloads.
Notice in the example that Aggregate Request Data is only collected for service
class BATCH. For batch workloads, we want to monitor and report their average
request execution times, which is collected for Aggregate Request Data.
Example 3-1 Creating service classes for basic setup
CREATE SERVICE CLASS
CREATE SERVICE CLASS
DISABLE;
CREATE SERVICE CLASS
DISABLE;
CREATE SERVICE CLASS
EXTENDED DISABLE;
CREATE SERVICE CLASS
EXTENDED DISABLE;
highlvl DISABLE;
admins UNDER HIGHLVL COLLECT AGGREGATE ACTIVITY DATA BASE
batch UNDER HIGHLVL COLLECT AGGREGATE REQUEST DATA BASE
prod_rpt UNDER HIGHLVL COLLECT AGGREGATE ACTIVITY DATA
prod_qry UNDER HIGHLVL COLLECT AGGREGATE ACTIVITY DATA
Note: When setting up your initial configuration, disable all service classes
and workloads until you are ready to use them. This keeps work from being
assigned a service class or workload prior to completing the WLM setup. In a
script the timing window may be small but when using the Command Line, the
exposure is much longer.
57
WLMDB
WL_BATCH
CLIENT_USERID = BATCH
WL_PROD_RPT
APPLNAME = dss.exe
User Requests
WL_PROD_QRY
SESSION_USER GROUP = DSSGROUP
WL_ADMIN
SESSION_USER GROUP = DB2ADM
Example 3-2 shows the workloads we set up, again, allowing the WLM setup to
evolve. (Note that although SYSDEFAULTUSERCLASS,
SYSDEFAULTSYSTEMCLASS, and SYSDEFAULTMAINTENANCECLASS are
automatically created, to keep things simple they are not shown here.)
Example 3-2 Creating workloads
CREATE WORKLOAD wl_batch CURRENT CLIENT_USERID ('BATCH')
DISABLE SERVICE CLASS BATCH UNDER highlvl POSITION AT 1;
CREATE WORKLOAD wl_prod_rpt APPLNAME ('dss.exe')
DISABLE SERVICE CLASS prod_rpt UNDER highlvl POSITION AT 2;
CREATE WORKLOAD wl_prod_qry SESSION_USER GROUP ('DSSGROUP')
DISABLE SERVICE CLASS prod_qry UNDER highlvl POSITION AT 3;
CREATE WORKLOAD wl_admin SESSION_USER GROUP ('DB2ADM')
DISABLE SERVICE CLASS admins UNDER highlvl POSITION AT 4;
58
Prior to DB2 9.5, these were set either using the client db2cli.ini or the set client
information API (sqleseti). Starting in DB2 9.5, the client identification can also be
set at the server. This adds flexibility to workload identification for work initiated
on the server or in a 3-tier environment.
In our case, we want all batch jobs to be identified by the client_userid BATCH.
Example 3-3 shows a batch job using the wlm_set_client_info stored procedure.
Example 3-3 Batch job using the wlm_set_client_info
db2
db2
db2
db2
connect to wlmdb
"call sysproc.wlm_set_client_info('BATCH',NULL,'MQT105',NULL,NULL)"
-tvf /batchjobs/mqt/refresh_mqt_current_yr_sls.clp
reset
59
user to run work in higher priority service classes by changing their client user ID,
client application name, client workstation name, and client accounting string to
match a higher priority service class.
Example 3-4 Grant workload usage
GRANT
GRANT
GRANT
GRANT
USAGE
USAGE
USAGE
USAGE
ON
ON
ON
ON
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
WL_ADMIN TO
WL_BATCH TO
WL_PROD_RPT
WL_PROD_QRY
PUBLIC;
PUBLIC;
TO PUBLIC;
TO PUBLIC;
Example 3-6 shows the event monitor tables created. We appended the event
monitor name to the table names to make them unique and to correlate them to
the event monitor. We created all the tables even though we were only
performing aggregate collection, which uses the tables:
SCSTATS
WLSTATS
HISTOGRANBIN
60
The other tables were created in case we needed them later. All the event
monitor tables are created in a specific tablespace as a good administration
practice. Placing the tables in a specific tablespace allows the DBA to determine
their location, tablespace type, and the amount of space allocated so they
potentially will not contend with production tables.
Example 3-6 Event monitor tables
->db2 list tables for user
Table/View
----------------------CONTROL_BASIC_MON
HISTOGRAMBIN_BASIC_MON
QSTATS_BASIC_MON
SCSTATS_BASIC_MON
WCSTATS_BASIC_MON
WLSTATS_BASIC_MON
Schema
-------ADMINHM
ADMINHM
ADMINHM
ADMINHM
ADMINHM
ADMINHM
Type
----T
T
T
T
T
T
Creation time
-------------------------2007-08-28-12.54.53.340071
2007-08-28-12.54.55.518744
2007-08-28-12.54.55.111208
2007-08-28-12.54.53.931222
2007-08-28-12.54.54.326150
2007-08-28-12.54.54.733324
Note that if this is the first occurrence of creating a workload, or if you are not
redoing the entire WLM setup, this statement is not needed. However, if you
have a script that is constructed to delete the prior WLM configuration, an
SQL4714N error may occur when all WLM service classes are disabled. The
reason for this is because if all service classes have been disabled, nothing else
in the script can execute until the work is routed to an enabled workload. So, this
is where SYSDEFAULTADMWORKLOAD is useful.
Example 3-7 shows a full script used in the test environment.
61
62
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
WL_ADMIN ENABLE;
WL_BATCH ENABLE;
WL_PROD_RPT ENABLE;
WL_PROD_QRY ENABLE;
COMMIT;
---------------------------------------------------------------- start using the new WLM setup
--------------------------------------------------------------SET WORKLOAD TO AUTOMATIC;
---------------------------------------------------------------- setup and turn on the event monitor
--------------------------------------------------------------CREATE EVENT MONITOR BASIC_MON FOR STATISTICS WRITE TO TABLE
SCSTATS (TABLE SCSTATS_BASIC_MON IN MAINT),
WCSTATS (TABLE WCSTATS_BASIC_MON IN MAINT),
QSTATS (TABLE QSTATS_BASIC_MON IN MAINT),
WLSTATS (TABLE WLSTATS_BASIC_MON IN MAINT),
HISTOGRAMBIN (TABLE HISTOGRAMBIN_BASIC_MON IN MAINT),
CONTROL (TABLE CONTROL_BASIC_MON IN MAINT)
AUTOSTART;
SET EVENT MONITOR BASIC_MON STATE 1;
Without the SET WORKLOAD TO SYSDEFAULTADMWORKLOAD command, after all the service
classes are disabled, the script cannot continue because we disabled every
service class we are using. An SQL4714N appears when the command shown is
attempted:
CREATE SERVICE CLASS HIGHLVL DISABLE;
63
HISTOGRANBIN_BASIC_MON
Each table gives us a different perspective of the WLM setup.
Looking at the SCSTATS_BASIC_MON, we can export and analyze our
workload at the subclass level. Example 3-8 shows the export SQL statements.
Example 3-8 Exporting event monitor data
EXPORT TO /tmp/exports/scstats_all.csv OF DEL
SELECT
DATE(statistics_timestamp) AS stat_date,
TIME(statistics_timestamp) AS stat_time,
SUBSTR(service_subclass_name,1,10) AS subclass_name,
CASE WHEN 0 > INT(SUM(concurrent_act_top))
THEN 0
ELSE INT(SUM(concurrent_act_top))
END AS con_act_top,
CASE WHEN 0 > INT(SUM(concurrent_connection_top))
THEN 0
ELSE INT(SUM(concurrent_connection_top))
END AS CON_CONN_TOP,
CASE WHEN 0 > INT(SUM(coord_act_completed_total))
THEN 0
ELSE INT(SUM(coord_act_completed_total))
END AS coord_act_comp,
CASE WHEN 0 > INT(SUM(coord_act_exec_time_avg))
THEN 0
ELSE INT(SUM(coord_act_exec_time_avg))
END AS avg_c_exe_tm,
CASE WHEN 0 > INT(SUM(request_exec_time_avg))
THEN 0
ELSE INT(SUM(request_exec_time_avg))
END AS avg_r_exe_tm
FROM scstats_basic_mon
WHERE CHAR(DATE(statistics_timestamp)) = CURRENT DATE
GROUP BY DATE(statistics_timestamp), TIME(statistics_timestamp),
SUBSTR(service_subclass_name,1,10)
ORDER BY 1,2,3
Note: Each column is summed because the SCSTATS table contains a row for
each partition, but the columns used contain values from the coordinator
partition, so the other partitions will have a zero (0) value and our query would
contain an error and not complete successfully.
From the SCSTATS_Basic_MON table, for each time period, we can analyze:
Top concurrent activity
64
Figure 3-4 shows the requests execution time by subclass on a typical day.
65
Production ad hoc queries begin at 8:00 am and run steadily until 8:00 pm.
Again, we have users in several time zones. We also see heavy CPU loads at
9:00 am and 4:00 pm.
The Admins appear to be running heavy loads twice a day, from 12 pm to
1:00 pm and from 6:00 pm to 8:30 pm. From our inquiry, we discover that the
online table space backups are run during these times daily.
We also see an unaccounted-for workload in the SYSDEFAULTSUBCLASS.
Someone is placing a very heavy load on the system around 11:30 am. More
investigation is needed to determine what is causing the additional load.
Using the same information, but now formatted as a stacked bar graph, we see
the accumulated effect of our workloads on the system as shown in Figure 3-5.
This graph gives us the total perspective of how the workloads impact our system
CPU consumption. Using this information, workloads can be rescheduled,
prioritized, or limited using queues if they consume too much CPU at the same
time.
66
We now turn our attention to concurrent top connections to get a sense of the
throughput of our work. This may not be an exact measurement of throughput,
but it does show how many queries are concurrently running throughout the day.
With many concurrent queries running, more resources could be needed, such
as memory, CPU, and higher disk activity. We get a sense of how many
workloads are running during the day, as shown in Figure 3-6 on page 67.
Using the concurrent_top_connections, we can analyze how many queries are
running concurrently throughout the day. We see from this graph that our
production ad hoc queries concurrency usually peaks twice a day. Our batch jobs
appear to taper off around 11 am.
We also see activity in the SYSTEMDEFAULTSUBCLASS during the prime shift
between 11:00 am and 1:30 pm. As seen in Figure 3-4 on page 65, this has a
severe impact on our CPU availability, and further investigation is warranted.
67
68
Restating the same information but as a stacked bar graph, we get an overall
view of the number of connections hitting our system throughout the day, as
shown in Figure 3-8 on page 69. We can see the high water mark for
connections, and notice that it occurs twice a day during prime shift. We can also
see which workloads are part of those peaks.
The spreadsheet shown in Figure 3-9 on page 70 displays the average execution
times of the coordinators. Using this information, we can examine the average
execution times for our workloads.
We want to know how long our ad hoc queries are averaging throughout the day
to determine whether we are meeting our business requirement that 90% of the
queries must complete within 5 minutes.
69
STAT_DATE
08/30/2007
Sum of AVG_C_EXE_TM
SUBCLASS_NAME
STAT_TIME
05.00.00
05.15.00
05.30.00
05.45.00
06.00.00
06.15.00
06.30.00
06.45.00
07.00.00
07.15.00
07.30.00
07.45.00
08.00.00
08.15.00
08.30.00
08.45.00
09.00.00
09.15.00
09.30.00
09.45.00
10.00.00
10.15.00
10.30.00
10.45.00
11.00.00
11.15.00
11.30.00
11.45.00
12.00.00
12.15.00
12.30.00
12.45.00
13.00.00
13.15.00
13.30.00
13.45.00
14.00.00
14.15.00
14.30.00
14.45.00
15.00.00
15.15.00
15.30.00
15.45.00
16.00.00
16.15.00
16.30.00
16.45.00
17.00.00
17.15.00
17.30.00
17.45.00
18.00.00
18.15.00
18.30.00
18.45.00
19.00.00
19.15.00
19.30.00
19.45.00
20.00.00
20.15.00
20.30.00
ADMINS
0
0
0
0
0
0
0
0
0
0
0
0
0
14
4
6
7
248
54
25
4
6
1
12
8
98
2
81
341123
4554
5433
4566
5122
5233
4123
3123
4313
4325
3577
3897
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
5244
4355
5342
5123
4154
5255
4897
5913
BATCH
PROD_QRY PROD_RPT
115480
0
0
121842
0
0
315415
0
0
288678
0
0
311042
0
0
278413
0
0
194998
0
423235
219847
0
221988
318917
0
435139
466125
0
323998
394941
0
505067
271321
18299
617513
187292
15180
838128
194941
39480
813949
187450
33501
721923
212344
97426
606466
254897
92160
1153193
287289
87491
497023
266211
105910
502287
287192
119525
200549
297173
270381
434342
351427
229025
403961
288743
207915
102538
294318
215363
281056
0
313948
149193
0
251136
293183
0
115679
412251
0
215431
204490
9441
168078
218723
65771
241140
50723
63577
153862
54974
449232
179481
136038
0
111407
48776
0
152984
155133
0
218971
62105
0
120988
27411
0
292914
124995
0
278114
396916
0
198929
671144
0
198228
290082
0
291991
123897
0
411288
87657
0
406283
139495
0
314949
194611
0
328321
233689
0
194680
203026
0
287790
206113
0
256131
157494
0
138139
61126
0
105284
59788
0
241871
62377
0
140988
248088
0
232914
189985
0
128114
315273
0
109929
535762
0
282453
219150
0
301456
488912
0
109387
153240
0
490063
563504
0
145531
149100
0
102162
166937
0
34583
39559
0
14742
0
70
Avg
PROD_QRY
SYSDEFAULT (minutes)
0
0
0
0
0
0
0
0
0
0
0
0
0.305
0
0.253
0
0.658
0
0.558
0
1.624
0
1.536
0
1.458
0
1.765
0
1.992
234
4.506
443
3.817
4643
3.465
3355
3.589
4346
5.232
46336
4.186
125335
1.928
134223
3.591
143543
2.801
334323
4.019
12233
2.564
24225
2.991
43253
1.857
53253
2.550
35424
3.650
35367
2.016
75643
4.882
46746
4.635
57876
3.315
75654
3.304
57886
4.867
75564
6.855
57886
6.771
67758
5.249
86576
5.472
65884
3.245
55776
4.797
5645
4.269
4567
2.302
7886
1.755
6896
4.031
9789
2.350
9769
3.882
7679
2.135
0
1.832
0
4.708
0
5.024
0
1.823
0
8.168
0
2.426
0
1.703
0
0.576
0
3.202
3.5 Summary
Now that we completed our cycle for the first time, what did we learn? Looking
back at our business requirements we see that not all of them are being met.
Batch ETL must complete prior to primetime (8 am), but we see from our charts
that batch runs past 8 am. In fact, batch appears to run until around 1 pm.
Ad hoc queries must compete 90% in under 5 minutes. If we assume the
coordinator execution time is representative of the overall query execution time,
we can extrapolate the average query execution time as 3.2 minutes, with only 6
time periods with an average execution time greater than 5 minutes (15:15,
15:30, 15:45, 16:00, 19:00, and 19.30). This appears to be within our business
requirement.
Production reports are completing but they start at 6:30 am and finish at
20:15 pm. So, we need to see why reports are being started so early.
We also see that there are workloads outside of our definition that need to be
more explicitly identified.
The analysis of the data will be the input for the next cycle using our WLM
methodology, as discussed in the following sections.
Identify
There are several areas we now want to identify for analysis.
Identify what is running in the SYSTEMDEFAULTSUBCLASS. We have
already identified all existing categories. Therefore, this work is probably
being performed by our report development group because it is the only
remaining group allowed access to our example database.
Limit the resources for the rouge queries based on execution time
The BATCH group runs two types of workloads, LOAD and our ETL tool
(etl.exe). We want to identify how much resource is being used for each of
these categories.
Manage
To reach the new goals we identified, we can alter our setup to the one shown in
Example 3-9. The alterations will drop the original BATCH service class and its
related workload and create two new services classes and workload in its place.
This will further divide the BATCH service class into ETL and LOADS for more
specific monitoring and reporting. Because aggregate request data is being
71
requested, we can monitor and report on average request execution times to see
how long these jobs run.
A new service class is also created to monitor and report on the activity of the
development groups activity and impact on the data warehouse. Using the
additional information, we may want to limit the number of queries, the amount of
resource, or both, that they can consume.
Example 3-9 Altered basic setup
ALTER WORKLOAD wl_batch DISABLE;
ALTER SERVICE CLASS BATCH UNDER highlvl DISABLE;
DROP WORKLOAD wl_batch ;
DROP SERVICE CLASS batch UNDER highlvl;
CREATE SERVICE CLASS batch_load UNDER highlvl COLLECT AGGREGATE REQUEST DATA
BASE DISABLE;
CREATE SERVICE CLASS batch_etl UNDER highlvl COLLECT AGGREGATE REQUEST DATA
BASE DISABLE;
CREATE SERVICE CLASS dev_rpt UNDER highlvl COLLECT AGGREGATE ACTIVITY DATA
EXTENDED DISABLE;
CREATE WORKLOAD wl_batch_etl APPLNAME ('etl.exe') DISABLE SERVICE CLASS
batch_etl UNDER highlvl POSITION AT 2;
CREATE WORKLOAD wl_batch_load CURRENT CLIENT_USERID ('BATCH') DISABLE SERVICE
CLASS batch_load UNDER highlvl POSIION AT 3;
ALTER WORKLOAD wl_prod POSITION AT 4;
ALTER WORKLOAD wl_admin POSITION AT 5;
CREATE WORKLOAD wl_dev_rpt SESSION_USER GROUP ('DEVGRP') DISABLE SERVICE CLASS
HIGHLVL POSITION AT 6;
GRANT USAGE ON WORKLOAD wl_batch_etl TO PUBLIC;
GRANT USAGE ON WORKLOAD wl_batch_load TO PUBLIC;
GRANT USAGE ON WORKLOAD wl_dev_rpt TO PUBLIC;
ALTER SERVICE CLASS batch_etl UNDER highlvl ENABLE;
ALTER SERVICE CLASS batch_load UNDER highlvl ENABLE;
ALTER WORKLOAD wl_batch_etl ENABLE;
ALTER WORKLOAD wl_batch_load ENABLE;
ALTER WORKLOAD wl_dev_rpt ENABLE;
COMMIT;
--- SETUP THRESHOLD AND MONITORING
--
72
Monitor
We will continue using the same high level reporting and repeating our analysis
and the WLM methodology cycle.
73
74
Chapter 4.
75
76
activity volume, and the success rates. Example 4-1 shows how to use this
table function to find out which applications are connected to the system.
Example 4-1 Workload occurrences on the system
>db2 "SELECT SUBSTR(service_superclass_name,1,19) AS superclass_name,
SUBSTR(service_subclass_name,1,19) AS subclass_name,
SUBSTR(workload_name,1,22) AS workload_name, application_handle,
workload_occurrence_state, SUBSTR(application_name,1,10) AS
application_name, SUBSTR(client_applname,1,10) AS client_applname
FROM TABLE(WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES('','',-2))"
SUPERCLASS_NAME
SUBCLASS_NAME
WORKLOAD_NAME
APPLICATION_HANDLE
WORKLOAD_OCCURRENCE_STATE
APPLICATION_NAME CLIENT_APPLNAME
------------------- ------------------- ----------------------------------------- ------------------------------- ---------------- --------------SYSDEFAULTUSERCLASS SYSDEFAULTSUBCLASS SYSDEFAULTUSERWORKLOAD
9 UOWEXEC
db2bp.exe
test
SYSDEFAULTUSERCLASS SYSDEFAULTSUBCLASS SYSDEFAULTUSERWORKLOAD
53 UOWWAIT
java.exe
account
2 record(s) selected.
service_superclass_name
service_subclass_name
application_handle
dbpartitionnum
You can use this table function to obtain a list of agents working in the
database. You can list all the agents running in a specific service class, or all
the agents working on the behalf of a particular application. You can also use
this table function to determine the state of the coordinator agent and
subagents for applications, and determine which requests each agent in the
system is working on. For example, if someone complains about a query not
running, you can find the workload occurrence and see what agents are
working on the query and what state they are in.
77
Example 4-2 lists the agents currently working on behalf of the applications
identified by application handle 9 and 53.
Example 4-2 Using WLM_GET_SERVICE_CLASS_AGENTS
>db2 "SELECT application_handle, SUBSTR(event_type,1,10) AS event_type,
SUBSTR(event_object,1,10) AS event_object, SUBSTR(event_state,1,10) AS
event_state, SUBSTR(request_type,1,10) AS request_type
FROM TABLE(WLM_GET_SERVICE_CLASS_AGENTS('', '', 9, -1)) AS agents"
APPLICATION_HANDLE EVENT_TYPE EVENT_OBJECT EVENT_STATE REQUEST_TYPE
-------------------- ---------- ------------ ----------- -----------9 PROCESS
ROUTINE
EXECUTING
OPEN
1 record(s) selected.
>db2 "SELECT application_handle, substr(event_type,1,10) as event_type,
substr(event_object,1,10) as event_object, substr(event_state,1,10) as
event_state, substr(request_type,1,10) as request_type
FROM TABLE(WLM_GET_SERVICE_CLASS_AGENTS('', '', 53, -1)) AS Agents"
APPLICATION_HANDLE EVENT_TYPE EVENT_OBJECT EVENT_STATE REQUEST_TYPE
-------------------- ---------- ------------ ----------- -----------53 WAIT
REQUEST
IDLE
COMMIT
1 record(s) selected.
WLM_GET_WORKLOAD_OCCURRENCE_ACTIVITIES
Table function parameters:
application_handle
dbpartitionnum
You can use this table function to obtain a list of current activities that are
associated with a workload occurrence. For each activity, the available
information includes the current state of the activity (for example, executing or
queued), the type of activity (for example, LOAD, READ, DDL), and the time
at which the activity started.
Example 4-3 shows all activities on the system from all applications. Two
applications are executing a SELECT, VALUES INTO, or XQuery statement.
Example 4-3 Activities on the system from all applications
>db2 "SELECT application_handle, local_start_time, activity_state,
activity_type FROM TABLE(WLM_GET_WORKLOAD_OCCURRENCE_ACTIVITIES(CAST(null
AS bigint), -1))"
APPLICATION_HANDLE
LOCAL_START_TIME
ACTIVITY_STATE
-------------------- -------------------------- ---------------
78
ACTIVITY_TYPE
----------------
READ_DML
READ_DML
2 record(s) selected.
Example 4-4 shows the total number of LOADs currently running on the
system.
Example 4-4 Number of LOAD activities on the system
>db2 "select count(*) as load_count from
table(wlm_get_workload_occurrence_activities(cast(NULL as bigint), -1))
where activity_type='LOAD'"
LOAD_COUNT
----------5
1 record(s) selected.
WLM_GET_ACTIVITY_DETAILS
Table function parameters:
application_handle
uow_id
activity_id
dbpartitionnum
You can use this table function to obtain the details about an individual
activity of an application. For example, for SQL activities, the available
information includes the statement text, package data, cost estimates, lock
timeout value, and isolation level.
Note that you need to turn on the statement monitor switch or the time stamp
switch to collect some elements (for example, CPU times and rows read or
modified). The value -1 means that either the statement monitor switch or the
time stamp switch is not activated.
Example 4-5 shows the details for the application with handle 18. It shows
details about the activity with unit of work ID 16 and activity ID 1.
Example 4-5 Capturing the individual activity
>db2 "SELECT SUBSTR(NAME, 1, 25) AS NAME, SUBSTR(VALUE, 1, 20) AS VALUE
FROM TABLE(WLM_GET_ACTIVITY_DETAILS(18,16,1,-2))
WHERE NAME IN ('COORD_PARTITION_NUM', 'APPLICATION_HANDLE',
'EFFECTIVE_ISOLATION', 'EFFECTIVE_LOCK_TIMEOUT', 'QUERY_COST_ESTIMATE')"
79
NAME
------------------------APPLICATION_HANDLE
COORD_PARTITION_NUM
EFFECTIVE_ISOLATION
EFFECTIVE_LOCK_TIMEOUT
QUERY_COST_ESTIMATE
VALUE
-------------------18
0
3
120
8
5 record(s) selected.
APPL_STATUS
---------------------CONNECTED
UOWWAIT
LOCKWAIT
CONNECTED
CONNECTED
UOWEXEC
CONNECTED
APPL_NAME
---------db2stmm
db2bp.exe
java.exe
db2evmg_DB
db2wlmd
db2bp.exe
db2taskd
7 record(s) selected.
80
81
4.2.3, Statistics event monitor on page 107, and explain how they are reset in
Resetting statistics on workload management objects on page 110.
Note: The monitoring table functions and stored procedures are activities (like
any other SQL) and as such are subject to monitoring. For example, if they are
run under a given service class, they will show up in the completed activity
counts for that service class.
If you want the statistics from user applications isolated from the statistics
from monitoring activities, consider isolating the user applications from the
monitoring activities; that is, run them in different service classes.
Table functions for obtaining statistics are:
WLM_GET_SERVICE_SUPERCLASS_STATS
Table function parameters:
service_superclass_name
dbpartitionnum
You can use this table function to show summary statistics across partitions
at the service superclass level. For example, knowing the high water marks
for concurrent connections is useful when determining peak workload activity.
Example 4-9 shows the concurrent connections for each service superclass.
Example 4-9 Using WLM_GET_SERVICE_SUPERCLASS_STATS
>db2 "SELECT * FROM TABLE(WLM_GET_SERVICE_SUPERCLASS_STATS('', -1))"
SERVICE_SUPERCLASS_NAME
DBPARTITIONNUM
CONCURRENT_CONNECTION_TOP
------------------------- -------------------------------------SYSDEFAULTSYSTEMCLASS
0
7
SYSDEFAULTMAINTENANCECLASS
0
2
SYSDEFAULTUSERCLASS
0
15
3 record(s) selected.
WLM_GET_SERVICE_SUBCLASS_STATS
Table function parameters:
service_superclass_name
82
LAST_RESET
-------------------------2007-08-17-08.25.53.703291
2007-08-17-08.25.53.703367
2007-08-17-08.25.53.703419
service_subclass_name
dbpartitionnum
You can use this table function to show summary statistics across partitions
at the service subclass level (all activities run in service subclasses).
Statistics includes the number of activities and average execution times. The
average execution time is useful to know when looking at general system
health and the distribution of activities across service classes and partitions.
Some statistics (for example, average activity lifetime) are only returned if
aggregate activity data collection (specified using the COLLECT
AGGREGATE ACTIVITY DATA clause) is enabled for the service subclass.
Other statistics (such as request execution time) depend on whether or not
aggregate request data collection (specified using the COLLECT
AGGREGATE REQUEST DATA clause) is enabled.
Example 4-10 shows the number of requests (NUM_REQUESTS_ACTIVE)
that are executing in the service subclass and the average request execution
time (REQUEST_EXEC_TIME_AVG). Notice that for all service subclasses
the average request execution time is NULL. This is because the COLLECT
AGGREGATE REQUEST DATA clause has not been specified for any of
these service subclasses.
Example 4-10 Using WLM_GET_SERVICE_SUBCLASS_STATS
>db2 "SELECT substr(service_superclass_name,1,19) as superclass_name,
substr(service_subclass_name,1,18) as subclass_name, num_requests_active,
request_exec_time_avg FROM TABLE(WLM_GET_SERVICE_SUBCLASS_STATS('','', -1))
ORDER BY superclass_name, subclass_name"
SUPERCLASS_NAME
SUBCLASS_NAME
NUM_REQUESTS_ACTIVE
REQUEST_EXEC_TIME_AVG
------------------- ------------------ ------------------------------------------SYSDEFAULTMAINTENAN SYSDEFAULTSUBCLASS
0
SYSDEFAULTSYSTEMCLA SYSDEFAULTSUBCLASS
5
SYSDEFAULTUSERCLASS SYSDEFAULTSUBCLASS
15
3 record(s) selected.
WLM_GET_WORK_ACTION_SET_STATS
Table function parameters:
work_action_set_name
dbpartitionnum
83
You can use this table function to show summary statistics across partitions
at the work action set level; namely, the number of activities of each work
class that had a work action from the corresponding work action set applied to
them. This is useful for understanding the effectiveness of a work action set
and understanding the types of activities executing on the system.
In Example 5-11, we are using the work action set and work class to
determine the number of large read activities running. The work_class_name
marked with an asterisk (*) represents all activities that did not fall into the
explicitly named work class LARGEREADS_QUERY. The value 3 means that
three activities of type LARGEREADS_QUERY had work actions applied to them
from the LARGEREADS_ACTIONSET work action set.
Example 4-11 Using WLM_GET_WORK_ACTION_SET_STATS
db2 "SELECT substr(work_action_set_name,1,20) as work_action_set_name,
substr(work_class_name,1,16) as work_class_name,
substr(char(act_total),1,14) as act_total, last_reset FROM
TABLE(WLM_GET_WORK_ACTION_SET_STATS (cast(null as varchar(128)), -1)) as
wasstats order by work_action_set_name, work_class_name"
WORK_ACTION_SET_NAME
--------------------LARGEREADS_ACTIONSET
LARGEREADS_ACTIONSET
2 record(s) selected.
WLM_GET_WORKLOAD_STATS
Table function parameters:
workload_name
dbpartitionnum
You can use this table function to show summary statistics across partitions
at the workload level. This includes high water marks for concurrent workload
occurrences and numbers of completed activities. Knowing these is useful
when you are monitoring general system health or drilling down to identify
problem areas.
Example 4-12 shows the highest number of concurrent occurrences and the
highest number of concurrent activities for each workload. The
CONCURRENT_WLO_ACT_TOP field is updated by each workload
occurrence at the end of its unit of work.
Example 4-12 Using WLM_GET_WORKLOAD_STATS
>db2 "SELECT substr(workload_name,1,22) as workload_name,
concurrent_wlo_top, concurrent_wlo_act_top FROM
84
WLM_GET_QUEUE_STATS
Table function parameters:
threshold_predicate
threshold_domain
threshold_name
threshold_id
You can use this table function to show summary statistics across partitions
for the WLM queues used for their corresponding thresholds. Statistics
include the number of queued activities (current and total) and total time
spent in a queue. This is useful when querying current queued activity or
validating if a threshold is correctly defined. Excessive queuing might indicate
that a threshold is too restrictive. Very little queuing might indicate that a
threshold is not restrictive enough, or is not needed.
Example 4-13 shows the CPU time consumed by each service class. From
the output we can learn which service class is consuming the most CPU
resources.
Example 4-13 Using WLM_GET_QUEUE_STATS
>db2 "SELECT substr(threshold_name, 1, 15) threshname, threshold_predicate,
threshold_domain, dbpartitionnum part, queue_size_top, queue_size_current,
queue_time_total, queue_assignments_total queue_assign FROM
table(WLM_GET_QUEUE_STATS('', '', '', -1))"
THRESHNAME
THRESHOLD_PREDICATE
THRESHOLD_DOMAIN PART
QUEUE_SIZE_TOP QUEUE_SIZE_CURRENT QUEUE_TIME_TOTAL
QUEUE_ASSIGN
--------------- --------------------------- ------------------ ------------------- ------------------ -------------------- -------------------QUEUE_THRESH
CONCDBC
SB
0
10
10
806299
17
1 record(s) selected.
85
agent_tid
agent_pid
application_handle
agent_id
agent_id_holding_lock
session_auth_id
session_auth_id
dbpartitionnum
node_number
utility_id
utility_id
workload_id
workload_id
SUBCLASS_NAME
CPU_TIME
------------------------- -------------------SYSDEFAULTSUBCLASS
47
SYSDEFAULTSUBCLASS
39
SYSDEFAULTSUBCLASS
0
3 record(s) selected.
86
You can use this stored procedure to cancel a running or queued activity. You
identify the activity by its application handle, unit of work identifier, and activity
identifier. Cancelling an activity will not terminate the connection. It only stops
the activity that was cancelled. If an application has several activities running
and only one needs to be stopped, cancelling the activity is a gentler
approach than forcing the application, which would terminate all activities.
The application with the canceled activity receives the error SQL4725N.
In Example 4-15, from window A, we first tried to cancel application 637 with
UOW ID 3 and ACTIVITY ID 1. This is not an existing activity, however, and
DB2 returns SQL4702N with SQLSTATE 5U035. We then successfully
cancelled application 637, UOW ID 1, ACTIVITY ID 1. In WindowB, we see
the application is canceled but the connection stays.
Example 4-15 Canceling an activity
WindowA:
>db2 CALL WLM_CANCEL_ACTIVITY(637,3,1)
SQL4702N The activity identified by application handle "637 [0-637]", unit
of work ID "3", and activity ID "1" does not exist. SQLSTATE=5U035
>db2 CALL WLM_CANCEL_ACTIVITY(637,1,1)
Return Status = 0
WindowB:
>db2 "SELECT * FROM employee FOR UPDATE"
EMPNO FIRSTNME
MIDINIT LASTNAME
WORKDEPT PHONENO HIREDATE
JOB
EDLEVEL SEX BIRTHDATE SALARY
BONUS
COMM
------ ------------ ------- --------------- -------- ------- ----------------------- --- ---------- ----------- ----------- ----------SQL4725N The activity has been cancelled. SQLSTATE=57014
87
=
=
=
=
=
=
WLM_CAPTURE _ACTIVITY_IN_PROGRESS
Syntax:
WLM_CAPTURE_ACTIVITY_IN_PROGRESS(application_handle, uow_id, activity_id)
You can use this stored procedure to send information about an individual
activity that is currently queued or executing to the active activities event
monitor. This stored procedure sends the information immediately, rather
than waiting until the activity completes. Before you call this stored procedure,
you need to activate an activity event monitor. If there is no active activities
event monitor, SQL1633W with SQLSTATE 01H53 is returned.
Example 4-16 shows how to use this stored procedure to collect the
estimated cost for a particular activity from the active activities event monitor.
SQL1633W is returned on the first stored procedure call because the event
monitor was not activated. After the event monitor was activated, the stored
procedure ran successfully and we could select data from the active activities
event monitor.
For more information about the activities event monitor, refer to the 4.2.1,
Activities event monitor on page 95.
Example 4-16 Capturing an activity
>db2 CALL WLM_CAPTURE_ACTIVITY_IN_PROGRESS(660,2,1)
Return Status = 0
SQL1633W The activity identified by application handle "660 [0-660]", unit
of work ID "2", and activity ID "1" could not be captured because there is
no active activity event monitor. SQLSTATE=01H53
>db2 set event monitor act state 1
DB20000I The SQL command completed successfully.
>db2 CALL WLM_CAPTURE_ACTIVITY_IN_PROGRESS(660,2,1)
Return Status = 0
88
WLM_COLLECT_STATS
Syntax:
WLM_COLLECT_STATS()
You can use this stored procedure to collect and reset statistics for workload
management objects. All statistics tracked for service classes, workloads,
threshold queues, and work action sets are sent to the active statistics event
monitor (if one exists) and then reset. If there is no active statistics event
monitor, the statistics are only reset; they are not collected.
Example 4-17 shows that the data of last_reset field is changed after calling
the WLM_COLLECT_STATS stored procedure. The evmon statistical tables
show that these tables contain the statistics that previously were being
reported by the table function. For more information about the statistics event
monitor, refer to Statistics event monitor on page 107.
Example 4-17 calling the WLM_COLLECT_STATS stored procedure
>db2 "SELECT service_superclass_name, concurrent_connection_top, last_reset
FROM TABLE(WLM_GET_SERVICE_SUPERCLASS_STATS('SYSDEFAULTUSERCLASS',-1))"
SERVICE_SUPERCLASS_NAME CONCURRENT_CONNECTION_TOP LAST_RESET
----------------------- ------------------------- ------------------------SYSDEFAULTUSERCLASS
4
2008-01-01-19.34.00.895855
1 record(s) selected.
>db2 "CALL WLM_COLLECT_STATS()"
Return Status = 0
>db2 "SELECT service_superclass_name, concurrent_connection_top, last_reset
FROM TABLE(WLM_GET_SERVICE_SUPERCLASS_STATS('SYSDEFAULTUSERCLASS',-1))"
SERVICE_SUPERCLASS_NAME CONCURRENT_CONNECTION_TOP LAST_RESET
----------------------- ------------------------- ------------------------SYSDEFAULTUSERCLASS
4
2008-01-01-19.34.56.354245
89
1 record(s) selected.
>db2 "select substr(service_superclass_name,1,20) as
service_superclass_name, concurrent_connection_top, last_wlm_reset,
statistics_timestamp from scstats_db2statistics where
service_superclass_name='SYSDEFAULTUSERCLASS'"
SERVICE_SUPERCLASS_NAME CONCURRENT_CONNECTION_TOP LAST_WLM_RESET
STATISTICS_TIMESTAMP
----------------------- ------------------------- -------------------------------------------------SYSDEFAULTUSERCLASS
4
2008-01-01-19.23.18.674420
2008-01-01-19.34.00.895855
SYSDEFAULTUSERCLASS
4
2008-01-01-19.34.00.895855
2008-01-01-19.34.56.354245
2 record(s) selected.
WLM_SET_CLIENT_INFO
Syntax:
WLM_SET_CLIENT_INFO(client_userid, client_wrkstnname,
client_applname, client_acctstr, client_workload)
You can use this procedure to set client information (client's user ID,
application name, workstation name, accounting, or workload information)
associated with the current connection to the DB2 server.
Example 4-18 shows how to use this stored procedure to set the client user
ID.
Example 4-18 Setting the client's user ID
>db2 CALL SYSPROC.WLM_SET_CLIENT_INFO('V95USER', NULL, NULL, NULL, NULL)
Return Status = 0
>db2 values(current client_userid)
1
--------------------------------------------------------------------------V95USER
1 record(s) selected.
90
= SYSDEFAULTUSERCLASS
= 3
= Service Superclass
91
Default Subclass ID
Service Class State
Agent Priority
Prefetch Priority
Outbound Correlator
Work Action Set ID
Collect Activity Opt
=
=
=
=
=
=
=
13
Enabled
Default
Default
None
N/A
None
Num Connections
Last Statistics Reset Time
Num Coordinator Connections
Coordinator Connections HWM
= 3
= 2007-08-17 08:25:53.000000
= 3
= 4
UOW ID
116
11
3
WLO State
UOWWAIT
UOWWAIT
UOWEXEC
Example 4-20 shows how we used db2pd to look at the thresholds to see in which
queue this agent is actually waiting. You can see the application handle 97 is
queuing the QUEUE_THRESH threshold.
Example 4-20 Check thresholds with db2pd
>db2pd -db sample -thresholds
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:36:13
Database Thresholds:
Service Class Thresholds:
Threshold Name
Threshold ID
Domain
Domain ID
Predicate ID
Maximum Value
Enforcement
Queueing
Queue Size
Collect Flags
Partition Flags
Execute Flags
Enabled
=
=
=
=
=
=
=
=
=
=
=
=
=
QUEUE_THRESH
1
30
3
90
50
D
Y
0
N
C
C
Y
92
UOW ID
93
evm-group value
Activities
CONTROL
ACTIVITY
ACTIVITYSTMT
ACTIVITYVALS
Threshold Violations
CONTROL
THRESHOLDVIOLATIONS
Statistics
CONTROL
SCSTATS
WCSTATS
WLSTATS
HISTOGRAMBIN
QSTATS
94
Example 4-22 shows to how to create an activities event monitor that writes
data to tables. Four tables are created.
95
To obtain a quick reference about the column name or the type name for
those event monitor tables, use the DESCRIBE TABLE command:
db2 describe table activity_db2activities
For more details about the information collected in the table, refer to the
Information Center:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/
2
-------Active
Inactive
2 record(s) selected.
$ db2 set event monitor wlm_act state 1
DB20000I The SQL command completed successfully.
$ db2 commit
DB20000I The SQL command completed successfully.
$ db2 "SELECT substr(evmonname,1,20) as evmonname, CASE WHEN
event_mon_state(evmonname) = 0 THEN 'Inactive' WHEN
event_mon_state(evmonname) = 1 THEN 'Active' END FROM syscat.eventmonitors"
96
EVMONNAME
-------------------DB2DETAILDEADLOCK
WLM_ACT
2
-------Active
Active
2 record(s) selected.
SUPERCLASSNAME
---------------------------SYSDEFAULTSYSTEMCLASS
SYSDEFAULTMAINTENANCECLASS
SYSDEFAULTUSERCLASS
-
COLLECTACTDATA
-------------N
N
N
N
N
N
6 record(s) selected.
$ db2 "alter service class SYSDEFAULTSUBCLASS under SYSDEFAULTUSERCLASS
collect activity data on all without details"
DB20000I The SQL command completed successfully.
$ db2 commit
DB20000I The SQL command completed successfully.
$ db2 "SELECT substr(serviceclassname,1,26) as
serviceclassname,substr(parentserviceclassname,1,28) as
superclassname,collectactdata FROM syscat.serviceclasses"
SERVICECLASSNAME
SUPERCLASSNAME COLLECTACTDATA
-------------------------- ---------------------------- -------------SYSDEFAULTSUBCLASS
SYSDEFAULTSYSTEMCLASS
N
97
SYSDEFAULTSUBCLASS
SYSDEFAULTSUBCLASS
SYSDEFAULTSYSTEMCLASS
SYSDEFAULTMAINTENANCECLASS
SYSDEFAULTUSERCLASS
SYSDEFAULTMAINTENANCECLASS
SYSDEFAULTUSERCLASS
-
N
W
N
N
N
6 record(s) selected.
98
$ db2 "create
subactservice
or
$ db2 "create
subactservice
DB20000I The
Example 4-26 shows the output of the activities event monitor for workload
ACTWORKLOAD with the COLLECT ACTIVITY DATA WITHOUT DETAILS option.
Example 4-26 COLLECT ACTIVITY DATA WITHOUT DETAILS option output
6) Activity ...
Activity ID
Activity Secondary ID
Appl Handle
UOW ID
Service Superclass Name
Service Subclass Name
:
:
:
:
:
:
1
0
113
1
ACTSERVICE
SUBACTSERVICE
Activity Type
:
Parent Activity ID
:
Parent UOW ID
:
Coordinating Partition
:
Workload ID
:
Workload Occurrence ID
:
Database Work Action Set ID
:
Database Work Class ID
:
Service Class Work Action Set ID :
Service Class Work Class ID
:
Time Created
:
Time Started
:
Time Completed
:
Activity captured while in progress:
READ_DML
0
0
0
3
2
0
0
0
0
2007-08-20 18:20:31.262589
2007-08-20 18:20:31.262602
2007-08-20 18:20:31.262887
FALSE
Application ID
Application Name
Session Auth ID
Client Userid
Client Workstation Name
Client Applname
*LOCAL.DB2_01.070821000549
java.exe
db2inst1
:
:
:
:
:
:
DB2_COMP
99
:
:
:
:
8
1
0.000284 seconds
1
Example 4-27 shows the output of the activities event monitor for workload
ACTWORKLOAD with the COLLECT ACTIVITY DATA WITH DETAILS option. The
activity statement section is added. From Statement text, we can identify which
query is being run by Appl Handle 352.
Example 4-27 COLLECT ACTIVITY DATA WITH DETAILS option output
5) Activity ...
Activity ID
Activity Secondary ID
Appl Handle
UOW ID
Service Superclass Name
Service Subclass Name
100
:
:
:
:
:
:
1
0
352
2
ACTSERVICE
SUBACTSERVICE
Activity Type
:
Parent Activity ID
:
Parent UOW ID
:
Coordinating Partition
:
Workload ID
:
Workload Occurrence ID
:
Database Work Action Set ID
:
Database Work Class ID
:
Service Class Work Action Set ID :
Service Class Work Class ID
:
Time Created
:
Time Started
:
Time Completed
:
Activity captured while in progress:
READ_DML
0
0
0
3
1
0
0
0
0
2007-08-20 17:58:44.740640
2007-08-20 17:58:44.740667
2007-08-20 17:58:44.741260
FALSE
Application ID
Application Name
Session Auth ID
Client Userid
Client Workstation Name
Client Applname
Client Accounting String
SQLCA:
*LOCAL.DB2_01.070821044851
java.exe
db2inst1
:
:
:
:
:
:
:
DB2_COMP
SQL0100W No row was found for FETCH, UPDATE or DELETE; or the result of a
query is an empty table. SQLSTATE=02000
Query Cost Estimate
Query Card Estimate
Execution time
Rows Returned
:
:
:
:
8
1
0.000592 seconds
1
:
:
:
:
1
0
*LOCAL.DB2_01.070821044851
2
:
:
:
:
:
:
:
:
:
:
:
:
-1
0
103079215105
NULLID
SYSSH200
: 2007-08-20 17:58:44.740640
: 2007-08-20 17:58:44.740640
1
Dynamic
0
0
Cursor Stability
SELECT NAME FROM STAFF WHERE ID = ?
Example 4-28 shows the output of the activities event monitor for workload
ACTWORKLOAD with the COLLECT ACTIVITY DATA WITH DETAILS AND VALUES
option. The activity data section is added. We can identify the value of parameter
marker. Before DB2 9.5, even if you use the statement event monitor, you cannot
collect the value of parameter marker.
Example 4-28 COLLECT ACTIVITY DATA WITH DETAILS AND VALUES option output
5) Activity ...
Activity ID
Activity Secondary ID
Appl Handle
UOW ID
Service Superclass Name
Service Subclass Name
Activity Type
Parent Activity ID
:
:
:
:
:
:
1
0
360
2
ACTSERVICE
SUBACTSERVICE
: READ_DML
: 0
101
Parent UOW ID
:
Coordinating Partition
:
Workload ID
:
Workload Occurrence ID
:
Database Work Action Set ID
:
Database Work Class ID
:
Service Class Work Action Set ID :
Service Class Work Class ID
:
Time Created
:
Time Started
:
Time Completed
:
Activity captured while in progress:
0
0
3
1
0
0
0
0
2007-08-20 18:13:28.207238
2007-08-20 18:13:28.207265
2007-08-20 18:13:28.207860
FALSE
Application ID
: *LOCAL.DB2_01.070821045412
Application Name
: java.exe
Session Auth ID
: db2inst1
Client Userid
:
Client Workstation Name
: DB2_COMP
Client Applname
:
Client Accounting String
:
SQLCA:
SQL0100W No row was found for FETCH, UPDATE or DELETE; or the result of a
query is an empty table. SQLSTATE=02000
Query Cost Estimate
Query Card Estimate
Execution time
Rows Returned
102
:
:
:
:
8
1
0.000595 seconds
1
:
:
:
:
1
0
*LOCAL.DB2_01.070821045412
2
:
:
:
:
:
:
:
:
:
:
:
:
-1
0
103079215105
NULLID
SYSSH200
: 2007-08-20 18:13:28.207238
1
Dynamic
0
0
Cursor Stability
SELECT NAME FROM STAFF WHERE ID = ?
: 2007-08-20 18:13:28.207238
position
type
set by reopt
is NULL
data
:
:
:
:
:
1
0
*LOCAL.DB2_01.070821045412
2
1
SMALLINT
FALSE
FALSE
10
103
104
Example 4-29 shows how to create a threshold violations event monitor that
writes data to a file.
Example 4-29 Creating a threshold violations event monitor file
$ db2 create event monitor wlm_thresh for threshold violations write to
file '/evmon/wlm/thresh'
DB20000I The SQL command completed successfully.
$ db2 "create event monitor wlm_act for activities write to file
'/evmon/wlm/activities' autostart"
DB20000I The SQL command completed successfully.
$ db2 commit
DB20000I The SQL command completed successfully.
105
5. Format the threshold violations event monitor file and see the output.
Example 4-32 shows the command and output of formatting the threshold
violations event monitor.
Example 4-32 Output of formatting the threshold violations event monitor
$ db2evmon -path /evmon/wlm/thresh > db2evmon1.out
$ more db2evmon1.out
<<extract from db2evmon1.out>>
5) Threshold Violation ...
Threshold ID
: 1
Activity ID
: 1
Appl Handle
: 337
Application ID
: *LOCAL.DB2_01.070821181355
UOW ID
: 1
Coordinating Partition : 0
Time of Violation
Threshold Max Value
Threshold Queue Size
Activity Collected?
Threshold Predicate
Threshold Action
:
:
:
:
:
:
2007-08-21 11:14:21.000000
10000
0
Yes
SQLRowsReturned
Stop
6. Format the activity event monitor file and see the output.
Example 4-33 shows the command and output of formatting the activity event
monitor. In our example, we only collected default activity information that
included SQLCODE, SQLSTATE and reason code. If you want to see which
query was violated by the threshold, you need to set COLLECT ACTIVITY
DATA WITH DETAILS or COLLECT ACTIVITY DATA WITH DETAILS AND
VALUES for the threshold.
Example 4-33 Output of formatting the activity event monitor
$ db2evmon -path /evmon/wlm/act > db2evmon2.out
$ more db2evmon2.out
<<extract from db2evmon2.out>>
31) Activity ...
Activity ID
: 1
Activity Secondary ID
: 0
Appl Handle
: 337
UOW ID
: 1
Service Superclass Name
: SYSDEFAULTUSERCLASS
Service Subclass Name
: SYSDEFAULTSUBCLASS
Activity Type
Parent Activity ID
Parent UOW ID
106
: READ_DML
: 0
: 0
Coordinating Partition
:
Workload ID
:
Workload Occurrence ID
:
Database Work Action Set ID
:
Database Work Class ID
:
Service Class Work Action Set ID :
Service Class Work Class ID
:
Time Created
:
Time Started
:
Time Completed
:
Activity captured while in progress:
0
1
2
0
0
0
0
2007-08-21 11:15:01.750519
2007-08-21 11:15:01.750557
2007-08-21 11:16:53.405745
FALSE
Application ID
: *LOCAL.DB2_01.070821181355
Application Name
: db2bp.exe
Session Auth ID
: db2inst1
Client Userid
:
Client Workstation Name
:
Client Applname
:
Client Accounting String
:
SQLCA:
SQL4712N The threshold "ROWSRETURNTHRESH" has been exceeded. Reason
code = "8". SQLSTATE=5U026
Query Cost Estimate
Query Card Estimate
Execution time
Rows Returned
:
:
:
:
6399
3869893
0.037908 seconds
10000
107
coord_act_completed_total
coord_act_rejected_total
coord_act_aborted_total
concurrent_act_top
Service superclass:
concurrent_connection_top
Workload:
concurrent_wlo_top
concurrent_act_top
coord_act_completed_total
coord_act_rejected_total
coord_act_aborted_total
wlo_completed_total
act_total
Threshold queues:
queue_assignments_total
queue_size_top
queue_time_total
108
cost_estimate_top
rows_returned_top
temp_tablespace_top
coord_act_lifetime_top
coord_act_lifetime_avg
coord_act_exec_time_avg
coord_act_queue_time_avg
activity lifetime histogram
activity execution time histogram
activity queue time histogram
cost_estimate_top
rows_returned_top
temp_tablespace_top
coord_act_lifetime_top
coord_act_lifetime_avg
coord_act_exec_time_avg
coord_act_queue_time_avg
activity lifetime histogram
activity execution time histogram
activity queue time histogram
coord_act_est_cost_avg
coord_act_interarrival_time_avg
activity inter-arrival time histogram
activity estimated cost histogram
coord_act_est_cost_avg
coord_act_interarrival_time_avg
activity inter-arrival time histogram
activity estimated cost histogram
request_exec_time_avg
request execution time histogram
109
110
Use the SET EVENT MONITOR STATE statement to activate the event
monitor as shown in Example 4-36.
Example 4-36 Setting the event monitor active
$ db2 set event monitor wlm_stats state 1
DB20000I The SQL command completed successfully.
111
Example 4-37 shows how to alter the default service class to specify the
COLLECT AGGREGATE ACTIVITY DATA BASE keyword.
Example 4-37 Using the ALTER SERVICE CLASS
$ db2 "alter service class SYSDEFAULTSUBCLASS under SYSDEFAULTUSERCLASS
COLLECT AGGREGATE ACTIVITY DATA BASE"
DB20000I The SQL command completed successfully.
112
To see the value of Request Execution Time Average, you need to specify
COLLECT AGGREGATE REQUEST DATA BASE option for the service
subclass.
Example 4-39 Output of formatting the statistics event monitor
647) Service Class Statistics ...
Service Superclass Name
: SYSDEFAULTUSERCLASS
Service Subclass Name
: SYSDEFAULTSUBCLASS
Service Class ID
: 13
Temp Tablespace high water mark
: 0
Rows Returned high water mark
: 262
Cost Estimate high water mark
: 1001074
Coordinator Completed Activity Count
: 78
Coordinator Aborted Activity Count
: 0
Coordinator Rejected Activity Count
: 0
Coordinator Activity Lifetime high water mark : 79
Coordinator Activity Lifetime Average
: 12
Coordinator Activity Queue Time Average
: 0
Coordinator Activity Execution Time Average
: 1
Coordinator Activity Estimated Cost Average
: -1
Coordinator Activity Interarrival Time Average: -1
Request Execution Time Average
: -1
Number Concurrent Activities high water mark : 1
Number Concurrent Connections high water mark : 4
Statistics Timestamp
: 2007-08-22 09:21:36.238396
Time of Last Reset
: 2007-08-22 09:16:36.231024
113
Every DB2 WLM histogram has 41 bins for the data collected. Each bin has the
range from top to bottom. You can see the number (frequency) of the activities or
requests within the range.
Example 4-40 shows the histogram section of a statistics event monitor output.
Three activities Number in bin have an execution time in the range zero (Bottom)
milliseconds to one (Top) milliseconds.
Example 4-40 Extract histogram output from statistics event monitor file
49) Histogram Bin ...
Top
Bottom
Number in bin
Bin ID
Service Class ID
Work Action Set ID
Work Class ID
Statistics Timestamp
Histogram Type
:
:
:
:
:
:
:
:
:
1
0
3
1
13
0
0
2007-08-22 14:09:05.488364
CoordActExecTime
114
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
2
3
4
5
7
10
13
17
23
31
42
56
74
100
133
177
237
316
421
562
749
1000
1333
1778
2371
3162
4216
5623
7498
10000
13335
17782
23713
31622
42169
56234
74989
100000
40 record(s) selected.
115
116
CoordActQueueTime
CoordActExecTime
CoordActLifeTime
CoordActInterArrivalTime
CoordActEstCost
117
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
25157
38373
58532
89280
136181
207720
316840
483283
737162
1124409
1715085
2616055
3990325
6086529
9283913
14160950
21600000
40 record(s) selected.
Use the SET EVENT MONITOR STATE statement to activate the event
monitor. Example 4-44 shows how to set the event monitor active.
Example 4-44 Setting the event monitor to active
>db2 "set event monitor db2statistics state 1"
DB20000I The SQL command completed successfully.
118
119
120
121
41 record(s) selected.
122
Chapter 5.
123
124
Business requirements
Identification
Action
Admin
group ID = DB2ADM
Batch
OLTP
executable = oltp.exe
DSS
Prime time 8 am to 8 pm
_ DSS queries
group ID =
DSSGROUP
_ DSS Analysis
Reports
exec = dss.exe
125
126
# lsuser db2inst1
db2inst1 id=1200 pgrp=db2adm groups=db2adm,staff,dasgrp
home=/db2home/db2inst1
shell=/usr/bin/ksh login=true su=true rlogin=true daemon=true
admin=false
sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM
auth2=NONE umask=22 registry=files SYSTEM=compat logintimes=
loginretries=0
pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1
minalpha=0 minother=0 mindiff=0 maxrepeats=8 minlen=8 histexpire=0
histsize=0 pwdchecks= dictionlist=
capabilities=CAP_NUMA_ATTACH,CAP_PROPAGATE fsize=-1 cpu=-1
data=-1 stack=-1 core=2097151 rss=65536 nofiles=-1
time_last_login=1189273673
time_last_unsuccessful_login=1188334437 tty_last_login=/dev/pts/0
tty_last_unsuccessful_login= host_last_login=9.26.92.65
host_last_unsuccessful_login=Clyde.itsosj.sanjose.ibm.com
unsuccessful_login_count=0 roles=
127
128
We need to identify our OLTP workloads so they are separated from the DSS
workloads and can be properly monitored and managed.
WL_OLTP identifies our OLTP transactions as being run using the
APPLNAME = oltp.exe
The priorities have been changed to put WL_OLTP at the top so that it can be
identified first and reduce the search time to identify our OLTP transactions.
Note: The workload definitions are searched in the order of their position. To
minimize search times, put the most critical workloads at the lowest position
number.
GRANT
GRANT
GRANT
GRANT
GRANT
USAGE
USAGE
USAGE
USAGE
USAGE
ON
ON
ON
ON
ON
ALTER
ALTER
ALTER
ALTER
ALTER
ALTER
SERVICE
SERVICE
SERVICE
SERVICE
SERVICE
SERVICE
ALTER
ALTER
ALTER
ALTER
ALTER
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
CLASS
CLASS
CLASS
CLASS
CLASS
CLASS
WL_ADMIN TO PUBLIC;
WL_BATCH TO PUBLIC;
WL_PROD_RPT TO PUBLIC;
WL_PROD_QRY TO PUBLIC;
WL_OLTP TO PUBLIC;
HIGHLVL ENABLE;
ADMINS UNDER HIGHLVL ENABLE;
BATCH UNDER HIGHLVL ENABLE;
PROD_RPT UNDER HIGHLVL ENABLE;
PROD_QRY UNDER HIGHLVL ENABLE;
OLTP UNDER HIGHLVL ENABLE;
WL_ADMIN ENABLE;
WL_BATCH ENABLE;
WL_PROD_RPT ENABLE;
WL_PROD_QRY ENABLE;
WL_OLTP ENABLE;
129
...
Service Class Name
= PROD_QRY
Service Class ID
= 19
Service Class Type
= Service Subclass
Parent Superclass ID
= 14
Service Class State
= Enabled
Agent Priority
= -5
Prefetch Priority
= Default
Outbound Correlator
= _HighLevel.Prod_QRY
Collect Activity Opt
= None
Collect Aggr Activity Opt = Extended
Collect Aggr Request Opt = Base
Act Lifetime Histogram Template ID
= 1
Act Queue Time Histogram Template ID
= 1
Act Execute Time Histogram Template ID
= 1
Act Estimated Cost Histogram Template ID
= 1
Act Interarrival Time Histogram Template ID = 1
Request Execute Time Histogram Template ID = 1
Access Count
Last Stats Reset Time
Activities HWM
Activities Completed
130
=
=
=
=
0
09/12/2007 12:51:02.000000
0
0
Activities Rejected
Activities Aborted
= 0
= 0
Associated Agents:
EDU ID
AppHandl [nod-index] WL ID
Activity ID
Associated Non-agent threads:
PID
TID
=
=
=
=
=
=
UOW ID
Thread Name
WLO ID
1
1
1
1
1
1
5
09/12/2007 12:51:02.000000
10
57
0
0
Associated Agents:
EDU ID
AppHandl [nod-index] WL ID
Activity ID
37671158153220
16372
[000-16372] 3
1
90838558310404
16373
[000-16373] 3
1
35407710388228
16374
[000-16374] 3
1
WLO ID
UOW ID
92
93
94
131
339061898215428
1
292723496058884
0
16378
[000-16378] 3
98
16379
[000-16379] 3
99
To check what priorities agents are using, we run the following command:
db2pd -db wlmdb -agent
Example 5-5 shows that we are running eight OLTP transactions and they are all
running at a priority of -10.
Note: The agent threads are set to a priority equal to the default priority, plus
the value set when the next activity begins.
In UNIX and Linux systems, the valid values are -20 to +20 (a negative value
indicates a higher relative priority). In Windows-based platforms, the valid
values are -6 to +6 (a negative value indicates a lower relative priority).
Example 5-5 db2pd agent priorities
10
0
1
10
Address
AppHandl [nod-index] AgentEDUID Priority Type
State
ClientPid Userid
ClientNm Rowsread
Rowswrtn
LkTmOt DBName
0x078000000023ACC0 67157
[001-01621] 9879
0
Coord
Inst-Active 2728214
dssuser db2stmm 0
0
NotSet WLMDB
0x078000000023EAE0 14189
[000-14189] 5032
0
SubAgent
Inst-Active 2928
PESRVUSR db2evmt_ 0
16592
3
WLMDB
0x0780000000942A00 17010
[000-17010] 10533
-10
SubAgent
Inst-Active 2199916
dssuser oltp.exe 2653
0
NotSet WLMDB
0x0780000000944180 17011
[000-17011] 10790
-10
SubAgent
Inst-Active 1679658
dssuser oltp.exe 2653
0
NotSet WLMDB
0x0780000000940080 17008
[000-17008] 10019
-10
SubAgent
Inst-Active 2666978
dssuser oltp.exe 2653
0
NotSet WLMDB
0x0780000000941540 17009
[000-17009] 3113
-10
SubAgent
Inst-Active 606550
dssuser oltp.exe 2653
0
NotSet WLMDB
132
0x0780000000945B40 17013
[000-17013] 11051
Inst-Active 1626264
dssuser oltp.exe 2653
0x0780000000947280 17015
[000-17015] 11309
Inst-Active 237574
dssuser oltp.exe 2653
0x07800000009489C0 17016
[000-17016] 11566
Inst-Active 2113846
dssuser oltp.exe 2653
0x078000000023D620 17014
[000-17014] 10289
Inst-Active 2146474
dssuser oltp.exe 2653
-10
0
-10
0
-10
0
-10
0
SubAgent
NotSet WLMDB
SubAgent
NotSet WLMDB
SubAgent
NotSet WLMDB
SubAgent
NotSet WLMDB
....
To check the prefetchers, we first switch to a data partition then run the db2pd
command as follows:
export DB2NODE=1
db2 terminate
db2pd -db wlmdb -edu -dbp 1
Example 5-6 displays the output.
Example 5-6 Output from db2pd -edu for prefetchers
TID
2941051
9401
9144
8887
8630
8373
8116
7859
7602
7345
7088
6831
6574
6317
6060
5803
Kernel TID
5906937
EDU Name
2265111
4682099
4853817
4166005
3194901
2793797
5435469
5853695
3690681
5816601
4448321
3068261
3444955
6455555
2044119
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
db2pfchr
USR
db2pfchr (WLMDB) 1
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
(WLMDB)
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
0.001099
0.001664
0.002559
0.001728
0.001910
0.002762
0.017083
0.048361
0.058649
0.057663
0.065778
0.066206
0.077666
0.075359
0.094211
SYS
0.001285
0.000597
0.001061
0.001224
0.001077
0.001030
0.001750
0.012175
0.039011
0.041682
0.044016
0.039444
0.045546
0.054751
0.048456
0.057868
133
(select BIN_TOP
, substr(SERVICE_SUBCLASS,1,15)
, NUMBER_IN_BIN
FROM histograms
where HISTOGRAM_TYPE = 'ReqExecTime'
order by 1,2
),
hist_colife ( bin, subclass, nbr_in_bin) as
(select BIN_TOP
, substr(SERVICE_SUBCLASS,1,15)
, NUMBER_IN_BIN
FROM histograms
where HISTOGRAM_TYPE = 'CoordActLifetime'
order by 1,2
),
hist_coexec ( bin, subclass, nbr_in_bin) as
(select BIN_TOP
, substr(SERVICE_SUBCLASS,1,15)
, NUMBER_IN_BIN
FROM histograms
where HISTOGRAM_TYPE = 'CoordActExecTime'
order by 1,2
),
hist_coarrive ( bin, subclass, nbr_in_bin) as
(select BIN_TOP
, substr(SERVICE_SUBCLASS,1,15)
, NUMBER_IN_BIN
FROM histograms
where HISTOGRAM_TYPE = 'CoordActInterArrivalTime'
order by 1,2
),
hist_cec ( bin, subclass, nbr_in_bin) as
(select BIN_TOP
, substr(SERVICE_SUBCLASS,1,15)
, NUMBER_IN_BIN
FROM histograms
where HISTOGRAM_TYPE = 'CoordActEstCost'
order by 1,2
)
select r.bin, r.subclass
, r.nbr_in_bin as ReqExecTime
, l.nbr_in_bin as CoordActLifetime
, e.nbr_in_bin as CoordActExecTime
, a.nbr_in_bin as CoordActInterArrivalTime
, c.nbr_in_bin as CoordActEstCost
134
4000
Number of Occurrences
3500
3000
2500
2000
1500
1000
500
-1
1
2
3
5
8
12
19
29
44
68
103
158
241
369
562
858
1309
1997
3046
4647
7089
10813
16493
25157
38373
58532
89280
136181
207720
316840
483283
737162
1124409
1715085
2616055
3990325
6086529
9283913
14160950
21600000
OLTP
PROD_QRY
PROD_RPT
Using the histogram, we can create a graph of the number of queries by request
execution times. This give us a quick glance at the types of queries (service
class) and how many queries ran within each time slot. Our OLTP is running
between .008 and 4.647 seconds. Our objective is to run all of our OLTP
135
transactions under 1 second, but we can see that 346 queries are outside of our
business objective.
Using the request execution times gives a useful picture because the request
time is the total time for the query, including any wait times. This objective will
need further analysis in order to determine why this is occurring: is it a problem
with the OLTP queries themselves, or some outside influence that is causing
them to not meet the runtime objectives?
The production queries (our second highest priority) are running between .029
and 1717.085 seconds (28.6 minutes). Our objective is to complete 95% in under
5 minutes. We completed a total of 21,286 transactions and 21,057 completed in
under 5 minutes. Our objective was 95%, we achieved 98.92%. Objective met!
As for our production reports, we ran 27, 572 reports during the period, with
approximately 52% of these queries completing in under 58 seconds. The
longest-running reports run in 2616.055 seconds or 43.6 minutes. This appears
to be a significant number of reports but with only a limited amount of data, it is
difficult to draw any meaningful conclusions. All were completed, but did they
interfere with any of our objectives? To determine this, we need more
information.
Next, we turn our attention to the arrival rates of our workloads. Figure 5-2
illustrates the arrival rates.
136
700
600
Number of Occurrence
500
400
300
200
100
21600000
9283913
14160950
3990325
6086529
2616055
1715085
483283
737162
1124409
316840
207720
89280
136181
58532
38373
25157
16493
7089
10813
4647
3046
858
1997
1309
562
369
241
68
158
103
44
29
19
12
3
5
-1
OLTP
PROD_QRY
PROD_RPT
Here we see how fast workloads are arriving in our system. So, are we
overloading our system at critical times? That is the question we want to answer.
Using the coordinator activity arrival times, we can chart how often workloads are
hitting the system.
Due to the large number of reports shown on the previous chart, and because we
missed our objective for some of the OLTP queries, our focus is on the
Production reports (PROD_RPT). From this graph we can see the PROD_RPTS
peak at nearly 200 arrivals that are 25 seconds apart. Is this the expected arrival
rate? Does the high arrival rate of PROD_RPTS interfere with our OLTP
transactions? The peak arrival rate for OLTP queries is 648 queries arriving
5.6 seconds apart. We need to examine when the PROD_RPT queries arrive by
looking at the aggregate service class statistics (SCSTATS_BASIC_MON) table.
From Example 5-1 on page 126, we can focus in on the request execution times
for specific time periods. Here we can see when the request execution times for
OLTP missed the targeted business objectives.
During the time frame of 14:00 to 17:30, the OLTP request times were
consistently out of our targeted business objectives of less than one second
execution time; see Figure 5-3.
137
12000000
10000000
8000000
6000000
4000000
2000000
0
2:00:50 2:15:50 2:30:50 2:45:50 3:00:50 3:15:50 3:30:50 3:45:50 4:00:50 4:15:50 4:20:50 4:45:50 5:00:50 5:15:50 5:30:50
PM
PM
PM
PM
PM
PM
PM
PM
PM
PM
PM
PM
PM
PM
PM
ADMINS
OLTP
PROD_QRY
PROD_RPT
Next, we need to look for the cause of the excessive OLTP request execution
times. The queries could be running long for several reasons, including that the
queries need tuning or that machine resources could be in short supply at
various times.
We can continue our analysis by looking at how much execution time is being
used by the various types of queries. Request execution time can be used for
such analysis, but with caution. The request execution time is the total time it
takes for a query to complete. This includes wait times as well as CPU time.
Nonetheless, we can use request execution times as a preliminary analysis tool.
From the chart shown in Figure 5-3, we have a clue. The PROD_RPT total
request executions times are also quite long, especially during the middle of the
day when many OLTP queries might also running. Because the OLTP queries
are quite short, they do not show up well on this chart, but our focus is on the
PROD_RPT request execution times. Because this represents a total request
execution time for all queries within each service class, we cannot tell if the long
execution time is the result of a few queries or many queries. So, what else can
we analyze to give a clearer picture?
138
In Figure 5-4, we look at the arrival times for workloads during the same time
frame as the Figure 5-3 chart on request execution times. Using the concurrent
activity top, we can create a chart to show when the highest concurrency of
activities for each service class is taking place.
700
600
500
400
300
200
100
0
14:00:50 14:15:50 14:30:50 14:45:50 15:00:50 15:15:50 15:30:50 15:45:50 16:00:50 16:15:50 16:20:50 16:45:50 17:00:50 17:15:50 17:30:50
ADMINS
OLTP
PROD_QRY
PROD_RPT
Here we see many workloads arriving at the same time by viewing the
concurrent active coordinator active. Notice the larger number of PROD_RPT
workloads.
Taking a closer look at the request execution times, we get a clearer picture of
the relationship between OLTP and PROD_RPTS. Using the data from the
SCSTATS table, we can construct a spreadsheet as shown in Figure 5-5 on
page 140. (Note that ADMIN subclass has been omitted for simplicity.)
139
AVG_R_EXE_TIME SUBCLASS_NAME
STAT_TIME
OLTP
PROD_QRY PROD_RPT
TOTAL_PROD
2:00:50 PM
323
77493
583391
660884
2:15:50 PM
924
97742
3991831
4089573
2:30:50 PM
981
329931
6164489
6494420
2:45:50 PM
2319
671233
7731281
8402514
3:00:50 PM
1989
876917
5677887
6554804
3:15:50 PM
487
12343
1476008
1488351
3:30:50 PM
781
74876
2225148
2300024
3:45:50 PM
849
89181
2199364
2288545
4:00:50 PM
842
87192
4143294
4230486
4:15:50 PM
911
61391
4140915
4202306
4:20:50 PM
926
81893
4832833
4914726
4:45:50 PM
2061
581773
7371625
7953398
5:00:50 PM
3269
41999
9198080
9240079
5:15:50 PM
3372
99719
10191323
10291042
5:30:50 PM
4639
671293
10822815
11494108
Figure 5-5 SCSTATS table of Request Execution Times
From this, we see that the OLTP queries are over our objective of one second
whenever the total request execution times are greater than 6500 seconds. We
also see some of the longest-running PROD_RPT queries during this time.
Now, we want to learn more about the PROD_RPTS for this time frame. In
Figure 5-6 on page 141, we focus on the costs of these reports.
140
12000000
10000000
Estimate Cost
8000000
6000000
4000000
2000000
17:30:50
17:15:50
17:00:50
16:45:50
16:20:50
16:15:50
16:00:50
15:45:50
15:30:50
15:15:50
15:00:50
14:45:50
14:30:50
14:15:50
14:00:50
Here we see the PROD_RPT queries cost vary greatly, but the more expensive
reports are being run during the same time frame as when our OLTP queries
begin to miss our business objectives. The PROD_RPT queries cost is greater
than 4,000,000 during our critical times for OLTP. We will want to limit them
during this time to lessen the impact on our OLTP queries.
5.5 Summary
Looking back at our earlier histogram chart, we see that the PROD_RPTS are
running near the top of the costs reported in the histograms. To summarize our
analysis so far, we see many PROD_RPTS running at the same time, and these
reports are the most expensive reports. At the same time, we see our OLTP
transactions begin to run longer and miss our targeted objectives. The cause
appears to be the long-running and expensive reports.
141
142
Chapter 6.
143
Predefined superclasses
The predefined AIX WLM superclasses are as follows:
Default superclass
All user processes belong to the default superclass, unless they are explicitly
defined to map to another superclass.
System superclass
The system superclass is the default superclass for all privileged processes
owned by root.
Shared superclass
The shared superclass receives all memory pages that are shared by
processes that belong to more than one superclass.
144
Unclassified superclass
When AIX WLM starts, all processes and memory pages are assigned to
certain superclass. The memory pages which cannot be tied to any specific
process will be mapped to this superclass.
Unmanaged superclass
This class is reserved for memory pages that are unmanaged by AIX WLM.
This superclass does not have any shares or limits for any resources. This
superclass does not have any subclasses. No processes will be assigned to
this superclass.
Figure 6-1 illustrates how resources are assigned with a default AIX WLM
configuration.
System
Default
Shared
Unclassified
Unmanaged
Predefined subclasses
Subclasses can have only one superclass. There are two predefined subclasses,
as explained here:
Default subclass
All processes which are not defined to any other subclass will be assigned to
the Default subclass.
145
Shared subclass
Like the Shared superclass, the Shared subclass contains all the memory
pages that contain processes belonging to more than one subclass under the
same superclass.
Tier
The tier defines the importance of the class. There are 10 levels of tiers, starting
from 0 to 9. Tier 0 is the most important level and has highest priority. If the tier
level 0 classes take up all the system resources, then tier level 1 classes will not
get any resources. If tier level 0 and tier level 1 classes are taking all system
resources, there will be nothing left for tier 2, and so on. If no tier value is defined,
the default value 0 will be used. Tier is defined both to superclasses and
subclasses.
Class limits and shares for CPU, memory, or disk I/O resource
A share defines the proportion of a resource that the process in a service class
can get. With shares, you can allocate a certain amount of CPU, memory, or I/O
resource to each service class. The resources will be allocated to a service class
in a relative way, depending on the number of total shares and the number of
shares the service class itself has.
146
For example, if we have a total of 1000 CPU shares for all superclasses, and
individual superclass db2Def has 400 CPU shares, then db2Def will get 40% of
all CPU resources. If we increase the number of total CPU shares for all
superclasses to 2000, then with its 400 CPU shares, db2Def would have 20% of
all CPU resources.
The resource share principle applies to memory and disk I/O resources, as well.
You can also define resource limits by percentage for different service classes.
The available limits are:
min
This specifies the minimum percentage of a resource that will always be
granted to a service class. The default is zero (0).
softmax
This specifies the maximum percentage of the resource that can be assigned
to a service class when there is contention, as explained here:
If there is no contention, then the service class can obtain more resources
than that specified by this attribute.
If there is contention, it is not guaranteed that the service class will get the
percentage of the resource specified by this attribute.
The default is 100.
hardmax
This specifies the maximum percentage of the resource assigned for a
service class when there is no contention. The default is 100.
Class assignment
There are two ways to classify processes to different service classes: using
manual classification, or using automatic classification. When you want to assign
processes manually to certain service classes, you can do it by using the
command wlmassign <PID>.
Automatic classification is done by following certain rules that are defined after
service class is defined. These rules can be defined in class assignment rules
that can contain following attributes:
Order of the rule: This is any number which defines the order of rules.
Class name: This defines to which class a process or thread will be mapped.
User and Group: These define by which user ID or group ID a process is
owned.
147
Application: This defines the full path name of the application, and it can
contain wild cards.
Tag: A label for identifying processes and threads that will be assigned by the
AIX WLM API call. DB2 uses tags to map DB2 WLM service classes to
certain AIX WLM service classes.
You can access class assignment rules either through smitty, or by editing a
special rules file. /etc/wlm/current/rules is the rules file for all superclases. For
subclasses, rules files are located under the corresponding superclass directory.
All superclass directories for running WLM configuration can be found under
directory /etc/wlm/current/<superclass name>.
6.1.2 Monitoring
There are many AIX WLM-aware operating system monitoring tools to monitor
AIX WLM:
wlmstat is similar to the use of vmstat or iostat.
nmon has AIX WLM enhancements.
topas is AIX WLM-aware.
ps is AIX WLM-aware: ps -m -o THREAD,class -p <process id>.
system
system
system
system
system
256
8192
0
256
18
Aug
Aug
Aug
Aug
Aug
28
27
21
28
28
18:11
16:35
12:35
18:11
18:11
.
..
.lock
.running
current ->
system
system
system
148
You can use /etc/wlm/template as a template for setting up your own AIX WLM
configuration. The steps are:
1. Copy the template to your desired directory:
cp -r /etc/wlm/template /etc/wlm/testenv
-a
-a
-a
-a
inheritance=no
inheritance=no
inheritance=no
inheritance=no
-c
-c
-c
-c
shares=60
shares=35
shares=25
shares=40
SaleSupClass
SaleSupClass.App1
SaleSupClass.App2
MktSupClass
149
150
simply by assigning 60 CPU shares for app1_app and 40 CPU shares for
app1_batch, for a total of 100 shares.
Figure 6-2 shows that our system reflects this setting. The x axis represents time
and the y axis represents the percentage of CPU that is consumed. The data is
from the nmon monitor tool. (We discuss this tool in nmon on page 167.)
In the figure, we see that by setting shares 60/40, subclass HighLevel.Prod gets
priority over subclass HighLevel.Util. When using shares, the average CPU time
inside the superclass Highlevel will be 60% for HighLevel.Prod and 40% for
HighLevel.Util.
Because we did not define any min, max, or hardmax values for our service
classes, there was no specific CPU usage percentage limits to be forced upon
both service classes. When we look at average data in the same time period, we
find that the average CPU for HighLevel. Prod was 60%, and the average CPU
for HighLevel.Utils was 40%, as illustrated in Figure 6-3.
151
We ran the same test without defining AIX WLM CPU shares. As you can see
from Figure 6-4, the result looks much different than when CPU shares were
defined.
152
Figure 6-5 Average CPU time by service class without CPU shares
153
154
DB2 Instance
AIX WLM
DB2Def Super Class
Database
Default System Super Class
Subclasses
DB2Def.System
Default Subclass
Default Subclass
DB2Def.HighLevelProd
Utils Subclass
DB2Def.HighLevelUtils
Web applications
Web.App1
WebApp2
Web.App2
When you are running a dedicated database server, we recommend that you use
the 1:1 mapping scheme, as illustrated in Figure 6-7.
155
DB2 Instance
Database
AIX WLM
Superclasses
Prod Subclass
Utils Subclass
The main difference between flat mapping and 1:1 mapping is that with 1:1
mapping, you can have identical superclasses and subclasses on both DB2
WLM and AIX WLM. This makes implementation and maintenance much easier.
We use a 1:1 mapping scheme for our example in this chapter.
156
Workloads
HIGHLVL
BATCH
WL_BATCH
PROD_QRY
WL_PROD_QRY
PROD_RPT
WL_PROD_RPT
ADMIN
WL_ADMIN
ADMINS db2HighLevel.Admins
PROD_QRY db2HighLevel.Prod_QRY
PROD_RPT db2HighLevel.Prod_RPT
BATCH db2HighLevel.Batch
157
DB2
AIX
Default System
_DefSystem
100 CPU
shares
Default
Default Subclass
Shared
Default User
30 CPU
shares
_DefUser
Default
Default Subclass
Shared
Default Maint
20 CPU
shares
_DefMaint
Default
Default Subclass
Shared
_HighLevel
HighLevel
200 CPU
shares
ADMINS
db2HighLevel.Admins
60 CPU
shares
db2HighLevel.Prod_QRY
60 CPU
shares
db2HighLevel.Prod_RPT
50 CPU
shares
_HighLevel.Admins
PROD_QRY
_HighLevel.Prod_QRY
PROD_RPT
_HighLevel.Prod_RPT
db2HighLevel.Batch
BATCH
_HighLevel.Batch
30 CPU
shares
Note that using the wlmcntr -ud command requires AIX WLM to be already
running. If AIX WLM is not running, use the command wlmcntrl -d product
instead.
Creating classes
After creating the configuration set, we can start configuring it. The first step is to
create four superclasses and four subclasses under superclass db2HighLevel,
as shown in Example 6-7.
158
mkclass
mkclass
mkclass
mkclass
mkclass
mkclass
mkclass
mkclass
-a
-a
-a
-a
-a
-a
-a
-a
inheritance=no
inheritance=no
inheritance=no
inheritance=no
inheritance=no
inheritance=no
inheritance=no
inheritance=no
-c
-c
-c
-c
-c
-c
-c
-c
shares=100 db2DefSystem
shares=20 db2DefMaint
shares=30 db2DefUser
shares=200 db2HighLevel
shares=30 db2HighLevel.Batch
shares=60 db2HighLevel.Prod_QRY
shares=50 db2HighLevel.Prod_RPT
shares=60 db2HighLevel.Admins
159
Note: Always leave the System class above the user-defined classes, so that
system processes will go to their default service classes. Also, leave the
Default user class below your user-defined classes.
Next, we define the mapping rules for subclasses under the db2HighLevel. The
corresponding rules file for the db2HighLevel is
/etc/wlm/current/db2HighLevel/rules. We edit this file as shown in Example 6-9.
Example 6-9 Rules for subclasses under superclass db2HighLevel
* class resvd user group application type tag
Batch - - - - - _HighLevel.Batch
Prod_QRY - - - - - _HighLevel.Prod_QRY
Prod_RPT - - - - - _HighLevel.Prod_RPT
Admins - - - - - _HighLevel.Admins
160
CPUshares = 200
db2HighLevel.Default:
db2HighLevel.Shared:
db2HighLevel.Batch:
inheritance = "no"
CPUshares = 30
db2HighLevel.Prod_QRY:
inheritance = "no"
CPUshares = 60
db2HighLevel.Prod_RPT:
inheritance = "no"
CPUshares = 50
db2HighLevel.Admins:
inheritance = "no"
CPUshares = 60
We test our configuration by checking to which AIX WLM service class the
processes and threads with AIX WLM tag _HighLevel.Batch are assigned. The
wlmcheck command can be used to check, as shown in Example 6-11.
Example 6-11 Test mapping rules
# wlmcheck -a "- - - - - _HighLevel.Batch"
System
db2HighLevel.Batch
As you can see from Example 6-11, all processes or threads which are tagged
with AIX WLM tag _HighLevel.Batch will be mapped to service subclass
db2HighLevel.Batch, unless the process or thread is owned by root. If process or
thread is owned by root, then it will be mapped to System Superclass. In our
case, all DB2 processes and threads are owned by instance owner db2inst1,
which ensures that our mappings will work as expected.
If your database is partitioned, you must set up AIX WLM on all physical nodes.
To set up another node, you only need to copy (using ftp or scp) the AIX WLM
configuration directory to that node and activate it. Example 6-12 shows how we
set up AIX WLM on the second physical database node Bonnie in our text
environment.
161
Note that the wlmcntrl command is executed without the -u flag because the AIX
WLM was not running when the command was executed.
162
_HighLevel;
You can check that the service class outbound correlators are set up properly by
looking the system catalog table SYSCAT.SERVICECLASSES, as shown in
Example 6-15.
Example 6-15 Check service class outbound correlator setting
db2 "select substr(char(SERVICECLASSID),1,2) as ID,
substr(SERVICECLASSNAME,1,19) as SERVICECLASSNAME,
substr(PARENTSERVICECLASSNAME,1,26) as PARENTSERVICECLASSNAME,
substr(OUTBOUNDCORRELATOR,1,19) as TAG from syscat.serviceclasses"
ID SERVICECLASSNAME
PARENTSERVICECLASSNAME
TAG
-- --------------------- -------------------------- -----------------1
2
3
11
12
13
14
15
16
17
18
19
SYSDEFAULTSYSTEMCLASS
SYSDEFAULTMAINTENAN
SYSDEFAULTUSERCLASS
SYSDEFAULTSUBCLASS
SYSDEFAULTSUBCLASS
SYSDEFAULTSUBCLASS
HIGHLVL
SYSDEFAULTSUBCLASS
ADMINS
BATCH
PROD_RPT
PROD_QRY
_DefSystem
_DefMaint
_DefUser
SYSDEFAULTSYSTEMCLASS
SYSDEFAULTMAINTENANCECLASS SYSDEFAULTUSERCLASS
_HighLevel
HIGHLVL
HIGHLVL
_HighLevel.Admins
HIGHLVL
_HighLevel.Batch
HIGHLVL
_HighLevel.Prod_RPT
HIGHLVL
_HighLevel.Prod_QRY
12 record(s) selected.
STIME
TTY
TIME CMD
163
0 15:48:10
0 15:48:11
2 15:48:10
- 1:24 db2sysc 1
- 0:09 db2sysc 2
- 1:07 db2sysc 0
1249349
3297525
3600475
3727573
700755
794987
1405319
1782027
4051391
S
S
S
S
S
S
S
S
S
0
0
0
0
0
0
0
0
0
60
60
60
60
60
60
60
60
60
1
1
1
1
1
1
1
1
1
...
...
...
...
...
...
...
...
...
400400
400400
400400
400400
400400
400400
400400
400400
400400
...
...
...
...
...
...
...
...
...
db2DefSystem
db2DefSystem
db2DefSystem
db2DefSystem
db2DefSystem
db2DefSystem
db2DefSystem
db2DefSystem
db2DefSystem
The first ps command is used to obtain the process ID for the db2sysc process
on partition0. Then we used this process ID to find out whether the DB2 agents
are mapped to AIX WLM service classes. This is a easy way to verify if the
mapping is working correctly.
You can also use the same approach to check whether the default maintenance
service class is mapped as defined. Before checking if the user-defined DB2
workloads are mapped to correct AIX service classes, first check whether the
workloads are mapped to correct DB2 service classes.
Now we have set up four user super service classes for AIX WLM. Three of them
are mapped to default DB2 WLM superclasses, and one is for the DB2 WLM
user superclass. Figure 6-10 illustrates how CPU resources are shared by AIX
WLM service superclasses.
164
The chart in Figure 6-10 on page 164 shows that our dedicated database server
is currently running quite a light load. There seems to be almost no CPU activity
for db2DefSystem and db2Defmaint. These classes are 1:1 mapped with DB2
service classes SYSDEFAULTSYSTEMCLASS and
SYSDEFAULTMAINTENANCECLASS.
There is no activity for db2DefUser at all, because currently no workloads are
mapped to DB2 WLM service class SYSDEFAULTUSERCLASS. db2HighLevel
has some activity, because all DB2 user workloads are running under this
service superclass.
From the chart you can also see that there is a gap between 18:32 and 18:33.
Because the chart only shows CPU activity, we should also examine memory
and disk usage to find out what caused the gap.
6.2.4 Monitoring
AIX offers excellent monitoring tools, and some of them are AIX WLM-aware.
These tools provide a quick way to monitor how the workloads are running on
their service classes. This gives us the capability to monitor the databases with
standard operating system monitoring tools much more effectively than ever.
topas
ps
wlmstat
nmon
Note that topas, ps, and wlmstat come with the standard AIX operating system.
You can freely download nmon from the following site:
http://www.ibm.com/collaboration/wiki/display/WikiPtype/nmon
topas
The topas tool is useful and user-friendly. You can use it to monitor your system
in real time. The topas tool provides a good view of overall system performance,
and you can include AIX WLM data. You can specify how many top AIX WLM
service classes you want to include in topas output by specifying the number of
WLM classes using the -w flag.
Figure 6-11 illustrates the output of topas -w 10.
165
To view only real time CPU usage between service classes, use topas -W.
Example 6-17 shows what the output may look like.
Example 6-17 Using topas for WLM monitoring
Topas Monitor for host:
2007
WLM-Class (Active)
System
db2DefSystem
db2DefMaint
db2DefUser
db2HighLevel
Unmanaged
Default
Shared
Unclassified
166
clyde
Interval:
CPU%
0
1
0
0
9
8
1
0
0
Mem%
5
2
0
0
12
4
5
2
4
Disk-I/O%
0
0
0
0
0
0
0
0
0
ps
The ps command is very useful for obtaining information about processes and
threads. In Example 6-15 on page 163, we show how to find the mappings
between DB2 service classes and AIX WLM service classes from DB2 side by
using the ps command. For more details about the ps command, refer to the AIX
manual pages.
wlmstat
If you are familiar with iostat and vmstat, you should have no difficulty using the
wlmstat command. It displays all the super classes and service classes with
current CPU, memory, and disk I/O usage; see Example 6-18. The wlmstat
command accepts two numeric input parameters. The first one is interval and the
second one is number of cycles. For more detailed usage information about the
wlmstat command, refer to the wlmstat manual pages.
Example 6-18 Using wlmstat for WLM monitoring
>wlmstat
CLASS CPU MEM DKIO
Unclassified 0
0 0
Unmanaged 0 16 0
Default 0 18 0
Shared 0 11 0
System 0
5 0
db2DefSystem 0
0 0
db2DefMaint 0
0 0
db2DefUser 0
0 0
db2HighLevel 0
0 0
db2HighLevel.Default
- db2HighLevel.Shared
- db2HighLevel.Batch
- db2HighLevel.Prod_QRY
- db2HighLevel.Prod_RPT
- db2HighLevel.Admins
- TOTAL 0 34 0
nmon
The nmon tool is a free tool for analyzing AIX performance. It is not part of the
standard AIX operating environment and is not officially supported by IBM. The
nmon tool has a user-friendly environment that is well-suited for real-time
monitoring. Using nmon, you can see your CPU, disk I/O, and memory usage in
real time on one screen. The rich monitoring capability has made nmon a very
popular tool for monitoring AIX and its resources. Because it has WLM
enhancements, we are able to use nmon to monitor AIX WLM.
167
Now that we have integrated the DB2 WLM with AIX WLM, we can see how the
DB2 workloads are behaving and compare the results with the overall operating
system performance. CPU utilization, Workload Manager activities, and memory
usage all can be seen real time in one screen, which is very useful in finding
bottlenecks and solving performance problems on the database system.
Figure 6-12 on page 169 presents simple real time monitoring for WLM
superclasses and subclasses. With a single glance, we see that currently our
four CPUs are utilized with 42.4% for user processes, 1.4% for system
processes, and 53.9% for I/O wait. We are using 6345.8 MB physical memory
and have 1846.2 MB free physical memory.
At the time of observation, all our workloads were executed on DB2 service
subclass PROD_RPT under HIGHLVL, which is mapped to AIX WLM service
subclass db2HighLevel.Prod_RPT. We could examine this data further, because
we would probably want to know what our CPUs are waiting for.
We can also look at the AIX WLM configuration from nmon real time data, and find
CPU shares and tiers for different DB2 service classes. By having all this
information at one central place, we are able to see how our overall system is
performing at a glance.
168
169
using operating system tools, then both DB2-related data and the entire
operating system-related data is collected.
The CPU gap could have happened if there were no queries at the time, but this
was not the case. We see that there was a peak for average execution time on
both PROD_RPT and PROD_QRY service classes at 6:32 pm. This peak can
imply a lack of operating system resources.
We then examine the operating system disk I/O activities at the time of this
incident by using the same data file collected by nmon. Figure 6-14 shows the disk
reads between 6:26 pm and 6:40 pm.
170
The disk reads in the chart are average for all the disks that belong to the datavg
volume group. This volume group holds all of our database-related data. There
was a high disk read period between 6:32 pm and 6:33 pm because the
operating system administrator mistakenly started the backup procedure for the
volume group, then corrected this action quickly. DB2 queries were in I/O wait
and did not consume CPU time.
We were able to determine the root cause for the relatively short service
breakdown by combining the usage of DB2 WLM and AIX WLM monitoring tools.
By using AIX WLM, you are also able to prioritize your database-related tasks
over other tasks to provide optimal database performance.
171
172
Chapter 7.
173
174
This creates an output file that can be input to nmon analyzer.xls. Both nmon and
the nmon analyzer.xls are available for download from the following IBM Wiki
Web site:
http://www.ibm.com/collaboration/wiki/display/WikiPtype/nmon
175
select
statistics_date,
statistics_hour,
subclass_name,
con_act_top,
avg_r_exe_tm,
decimal(avg_r_exe_tm / con_act_top,9,3) as avg_r_exe_tm_per_act
from (select
date(statistics_timestamp) as statistics_date,
hour(statistics_timestamp) as statistics_hour,
substr(service_subclass_name,1,15) as subclass_name,
case when 1 > int(sum(concurrent_act_top))
then 1
176
else int(sum(concurrent_act_top))
end as con_act_top,
case when 1 > int(sum(request_exec_time_avg))
then 1
else decimal(sum(request_exec_time_avg) / 1000,9,3)
end as avg_r_exe_tm
from scstats_basic_mon
where
service_subclass_name in ('PROD_RPT', 'PROD_QRY')
group by date(statistics_timestamp), hour(statistics_timestamp),
service_subclass_name
order by date(statistics_timestamp), hour(statistics_timestamp),
service_subclass_name);
After collecting the data, we can create various charts for analysis. For this
example, we have collected three weeks of data, covering the prime time hours.
Our first chart, shown in Figure 7-2 on page 178, is the total request execution
times across all data partitions for both PROD_QRY and PROD_RPT service
classes. For ease of viewing, only the prime time hours are shown, because this
is our main area of focus.
From this chart, we can see which hours have the highest request execution
times, and whether a trend appears to be established. Here we clearly see that
11 am shows the highest total request execution times. Additionally, we appear
to have established an upward trend in request execution times. Notice that the
request execution time drops off dramatically after 5 pm, and continues to remain
low for the rest of the prime time shift.
177
35000
30000
25000
20000
15000
10000
5000
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
0
8
10
11
12
13
14
15
16
17
18
19
20
PROD_QRY
PROD_RPT
Figure 7-2 Total Request Execution times in seconds, across all partitions
Next, we compare the CPU utilization across the same time periods to give us a
perspective of how our total request executions times related to CPU
consumption. In Figure on page 180, we see the total CPU percentage for all our
partitions. This can easily be captured using vmstat or nmon.
178
100%
90%
80%
CPU Percentage
70%
60%
50%
40%
30%
20%
10%
0%
8
10
11
12
13
14
15
16
17
18
19
20
Now we can put the previous chart into perspective. We see that our peak CPU
consumption is at 11 am. We top out at 90% when the total request execution
time is 32,635 seconds. Therefore, we can make a basic assumption that we
reach maximum consumption at 100% when we reach a total request execution
time of 36,261 (32,635/.90) seconds. Other factors play into CPU consumption
but for basic planning purposes, this gives a simple model.
Next, we need to analyze whether any correlation exists between request
execution times and the number of active concurrent workloads. Figure 7-4 on
page 180 displays a chart showing the number of top concurrent workload
activities for the same time periods.
179
180
160
140
Active Connections
120
100
80
60
40
20
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
0
8
10
11
12
13
14
15
16
17
18
19
20
PROD_QRY
PROD_RPT
Figure 7-4 Number of top concurrent workloads activities for time periods
Here we see a slightly different picture: we have two periods of high workloads,
11 am and 2 pm. The difference must be in the average request execution times
for each workload activity. Figure 7-5 on page 181 displays a chart showing the
average request execution time for average concurrent workloads.
180
900.000
800.000
700.000
600.000
500.000
400.000
300.000
200.000
100.000
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
0.000
8
10
11
12
13
14
15
16
17
18
19
20
PROD_QRY
PROD_RPT
As you can see, our most expensive requests are submitted during lunch time,
at 12 pm. We can also confirm that the workloads at 2 pm are slightly more
CPU-intensive then those submitted at 11 am.
All of our charts confirm that a linear correlation exists between Request
Execution times and Percentage of CPU. As the total request execution time
goes up, so does the total percentage of CPU.
This is important to establish and understand, because if there is no linear
relationship between these two factors, it indicates that other factors may be at
play. The other factors could be lock waits or slow disk access times, or perhaps
there is not enough memory and paging is occurring. A more comprehensive set
of reports with additional information would then be needed in order to effectively
analyze these additional factors.
181
182
The example used in this section shows two instances of DB2, with each
instance containing a database. This might be a typical OLTP environment
where the two databases are in their own instances to allow for separate
configurations. This arrangement also insures stability between databases, as
well as the independence to start and stop DB2 when needed. We want each
instance and database charged to its respective department.
-- instance db2inst01
CREATE SERVICE CLASS HIGHLVL DISABLE;
CREATE SERVICE CLASS SALES UNDER HIGHLVL COLLECT AGGREGATE REQUEST DATA
BASE DISABLE;
ALTER SERVICE CLASS SALES ENABLE;
CREATE EVENT MONITOR BASIC_MON FOR STATISTICS WRITE TO TABLE
SCSTATS (TABLE SCSTATS_BASIC_MON IN MAINT)
AUTOSTART;
SET EVENT MONITOR BASIC_MON STATE 1;
183
-- instance db2inst02
CREATE SERVICE CLASS HIGHLVL DISABLE;
CREATE SERVICE CLASS SALES UNDER HIGHLVL COLLECT AGGREGATE REQUEST DATA
BASE DISABLE;
ALTER SERVICE CLASS SALES ENABLE;
CREATE EVENT MONITOR BASIC_MON FOR STATISTICS WRITE TO TABLE
SCSTATS (TABLE SCSTATS_BASIC_MON IN MAINT)
AUTOSTART;
SET EVENT MONITOR BASIC_MON STATE 1;
7.2.3 Monitoring
After we have run our WLM setup for a week, we can analyze our data. Using the
query in Example 7-3, we can capture the chargeback data from each instance.
Because the event monitor names are the same but the super class names are
unique, we simply run the query in both instances.
Example 7-3 Query to collect chargeback accounting data
select
statistics_date,
superclass_name,
decimal(avg_r_exe_tm / con_act_top,9,3) as avg_r_exe_tm_per_act
from (select
date(statistics_timestamp) as statistics_date,
substr(service_superclass_name,1,15) as superclass_name,
case when 1 > decimal(sum(request_exec_time_avg),9,3)
then 0
else decimal(sum(request_exec_time_avg) / 1000,9,3)
end as avg_r_exe_tm
from scstats_basic_mon
group by date(statistics_timestamp), service_superclass_name)
order by date(statistics_timestamp), service_superclass_name);
From this data we can create a spreadsheet, as shown in Table 7-1 on page 184.
Table 7-1 Chargeback accounting spreadsheet
Total Request Execution Times
Percentage chargeback
STATISTICS_DATE
ACCOUNTING
SALES
Grand total
ACCOUNTING
SALES
08/27/07
98,940.58
218,744.34
317,684.93
31.144
68.856
184
Percentage chargeback
STATISTICS_DATE
ACCOUNTING
SALES
Grand total
ACCOUNTING
SALES
08/28/07
57,731.21
221,394.80
279,126.02
20.683
79.317
08/29/07
80,126.25
229,726.85
309,853.11
25.859
74.141
08/30/07
111,796.64
224,795.77
336,592.41
33.214
66.786
08/31/07
89,442.65
235,012.39
324,455.05
27.567
72.433
Note that the total times vary from day to day, but the percentage calculations
are based on the total for the particular day. This way each department is
charged for their percentage of use that day, and the sum of the percentages is
always 100%. If, for example, SALES was the only instance running that day, IT
would be charged 100%. This eliminates having a shortfall or gap in accounting
for the machine usage.
Because we are only using DB2 WLM Request Execution times, we have to
assume that the other DB2 processes are not accounted for in WLM. Here is a
partial list of entities that do not work within a database and are not tracked by
service classes:
185
100%
90%
80%
Percentage of Use
70%
60%
50%
40%
30%
20%
10%
0%
08/27/2007
08/28/2007
08/29/2007
ACCOUNTING
08/30/2007
08/31/2007
SALES
186
Chapter 8.
187
188
189
190
191
The perspectives control what the Design Studio displays, including certain
menus and tool bars.
Perspectives
When you open the Design Studio, it takes you to the default Business
Intelligence (BI) perspective. This view contains various resources that can be
used to accomplish a particular task or work with a particular resource. Certain
menu options are enabled or disabled, based on your current perspective.
Additional perspectives can be opened based on your needs. Perspectives
provide the functionality required to accomplish a particular task with a particular
resource.
To open additional perspectives, click Window -> Open Perspective -> Other
and select the desired perspective.
To reset a perspective to its original layout, click Window -> Reset Perspective.
192
Views
A view is a visual component of Design Studio used to display properties, tree
structure, and access to editors. Views can be used to navigate Data Project
Explorer and Database Explorer information trees, open the related editors, or
display and review properties. When you modify the information in a view,
Design Studio saves it immediately. To open a closed or hidden view, click
Window -> Show View and select the view.
Properties view
This view is open by default in the lower right area of Design Studio. You can use
the Properties view to define and modify many of the objects that you create. In
addition, from this view you can see other views such as Data Output, Problems,
Execution Status and Job Status. To make any of these views active, click the
title tab, which brings the Properties view to the foreground.
You can use the Properties view to define and modify many of the objects that
you create. To open the Properties view when it is closed or hidden, click
Window -> Show View -> Properties.
Note: If you cannot find an option or control that you expected to work with,
verify that you have opened the correct view.
Editors view
The Editors view opens by default in the upper right area of the Design Studio
canvas. It also opens up a palette for graphic editors, on the right side of the
canvas, based on the object type you are working with.
193
An editor is a visual component of the Design Studio that you typically use to
browse or modify a resource, such has an object in a project. The available
options are Text Editor, System Editor (operating system), and In-line Editor,
based on the project scheme or objects.
Note: There is no automatic save option for these editors, so you must
explicitly save the changes.
Projects
A project is a set of objects that you create in Design Studio as part of the data
transformation or warehouse building processes. You must create a project in
Design Studio before creating WLM objects. Each project that you build is
represented by an icon in the Data Project Explorer, where you can expand it,
explore its contents, and access editors to work with it. You create different types
of objects, according to the type of project you are building.
You can integrate the project file workspace directory with the concurrent
versions system (CVS). In a coordinated development environment, this will
enable you to share the project with other developers.
194
Superclass
Service superclass
Subclass
Service subclass
Work identity
Workload
Work type
Work class
On Design Studio, when you create a new scheme, it can be viewed in more
than one way. You can see the DB2 WLM entities using:
The tree view
The grid view
Figure 8-4 on page 195 shows a Design Studio tree view with WLM entities.
Figure 8-5 shows the Design Studio WLM entities in grid view.
195
When you create a new scheme, Design Studio automatically creates containers
for entities that make up a scheme. The containers created by Design Studio are:
Database service classes
Based on the definition, all of the work for a database is executed in the
database service classes.
Operating system service classes
If you run the database on AIX, use operating system service classes to
allocate CPU shares for database work. Operating system service classes
are created with a new scheme only when reverse engineering is used.
Work identities
Work identities define the work to be controlled based on connection
attributes, like user or application name.
Work type sets and work types
Classify the database work into sets of work types, such as DML, DDL, Read,
Write, LOAD, CALL and so forth. Work types are then mapped to the
database subclasses that execute the work.
Note: Work type sets and work types are never created for you as part of
creating a new scheme; they must be created separately.
Histogram templates
Histogram templates are used to determine the high bin values for a
histogram. You can create custom templates for the histograms that display
your monitoring data, or use the default templates.
196
You can use a data warehouse project for designing and building the DB2
workload management objects. Before starting to do any work, create a project
from File -> New -> Data Warehouse Project; see Figure 8-6.
In this example, we create a new project WLMDB.
197
WLM scheme for the first time, Design Studio creates a file with a .wlms file
extension for the scheme, using the scheme name you specified under the
workspace directory. Design Studio displays the complete path in the Overview
tab.
To create WLM Scheme, expand the project tree view (WLMDB, in our example),
and then right-click Workload management scheme -> New -> Workload
Management Scheme; see Figure 8-7 on page 198.
When you select New Workload Management Scheme, it takes you to the New
File for Workload Management Scheme panel (Figure 8-8 on page 199), where
you can give a scheme name and select one of the three methods to create the
scheme:
Create a scheme by objective
Create a scheme yourself
Create a scheme by reverse engineering
We discuss each scheme creation method in detail in the following sections.
198
199
200
201
The Control and Share System Resources panel (Figure 8-11 on page 202) is
then presented with four tabs labeled General, Work Identities, Superclasses,
and Create Relationships. Each tab allows you to create specific DB2 workload
objects.
Note: Clicking OK at any tab takes you back to the Business Intelligence view,
and not to the next tab. Design Studio will create only the default objects for
those unvisited tabs.
So to continue working on the scheme using the guided configuration, select
the WLM scheme -> Workload Management, and then select the guided
configuration you want.
202
2. Work Identities
You can use this tab to add a new DB2 WLM workload, or to delete or modify
an existing workload.
Because there are no existing user-defined workloads, the default workloads
SYSDEFAULTUSERWORKLOAD and SYSDEFAULTADMWORKLOAD are
listed. To add a workload, click Add and the Work Identity property view was
presented; see Figure 8-12 on page 203. You can identify the connection
attributes to be used in your workload.
To see the description of a field, left-click the field name.
The capitalized fields in the Work Identity panel match the attributes in the
DB2 CREATE WORKLOAD statement. The three authorization fields are for
granting workload execution authority.
In our case, we created a workload WI_PROD to manage application
dss.exe. The workload can be used by everyone (public). We selected the
Superclasses tab to proceed.
203
Notes:
If you do not specify a value for a connection property, DB2 matches for all
of the values of the property, as if you had specified a wildcard.
When you specify values for multiple connection properties (such as
application name and system user), then the values are interpreted as the
application name and the system user. For example, if you enter dss.exe
in APPLNAME and Bob in SYSTEM_USER, the values are interpreted as
dss.exe + Bob as the connection property.
If you type multiple values for the same connection property in a
comma-separated list, each value in the comma-separated list is
connected to the next by or. For example, if you enter Mary, Bob, John in
the SESSION_USER field, the values are interpreted as Mary or Bob or
John.
3. Superclasses
Figure 8-13 on page 205 shows the Superclasses tab with three default
superclasses: SYSDEFAULTUSERCLASS, SYSDEFAULTSYSTEMCLASS,
and SYSDEFAULTMAINTENANCELASS. Use this tab to add new
superclasses, or to delete or modify existing superclasses.
204
To create a new superclass, click Add and the Superclass property view will
be presented; see Figure 8-14 on page 206.
Here you enter the name of the superclass to be created, the agent and
prefetch priority, and work action set name, if already known. These fields
match the AGENT PRIORITY, PREFETCH PRIORITY in the DB2 CREATE
SERVICE CLASS statement.
205
If your operating system is AIX and you are using AIX WLM, you can
associate the superclass with the Operating system class by selecting the
browse button
. This will take you to Select Operating system Service
Class panel (Figure 8-15).
To create a new operating system service class, expand the WLM scheme,
select Superclass, and click Create.... For this example, we created an
operating system class DB2SC for DB2 resources; see Figure 8-16. Clicking
OK takes you back to the Select Operating System Service Class to allow you
to create more operating system service classes.
206
After you have completed creating operating system service classes, select
any operating system service class to make the OK button active and then
click OK. Design Studio takes you back to Superclass property view showing
the new operating system service class associated with DB2 Superclass; see
Figure 8-17.
Figure 8-17 DB2 Superclass with AIX Operating System Service class
207
4. Create Relationships
By default, workloads are associated with the default superclass. You can
use this tab to customize the relationships between the work identities,
superclasses, and operating system service classes. Figure 8-19 on
page 209 shows all the defined workloads are listed under Work Identity
column.
208
209
210
Figure 8-21 Control and Share System Resources - Create Relationships view
When you click OK, Design Studio creates a WLM scheme and takes you
back to the default Business Intelligence (BI) perspective.
In the BI perspective, Design Studio focuses you on the Editors panel and give
the overview of the current project created. The project created for this example
is WLMDEMO_BY_OBJ, as shown in Figure 8-22 on page 212.
Note: Design Studio does not save the scheme automatically. To save your
scheme, use File -> Save or the
icon.
211
If you select the Scheme tab in the BI perspective, you can see the tree structure
of the WLM scheme you created; refer to Figure 8-23 on page 213. From the tree
view, you can further modify the work scheme you created.
212
Validating
After the workload scheme is created, you can use the Design Studio Validate
option to validate the workload, service classes, and the relationship you just
created. Design Studio validates all the resources on the selected project using
validation settings.
213
To validate the WLM scheme, select Workload Management -> Validate. When
the validation of a WLM scheme succeeds, the Design Studio displays a
confirmation message as shown in Figure 8-24 on page 214.
Generating code
After successful validation, you can generate code using Workload
Management -> Generate Code. For each code file generated, Design Studio
presents it as a tab in the BI perspective Editors view.
In our example, two files (WLMDEMO_BY_OBJ.wlmsql and
WLMDEMO_BY_OBJ.osclasses) are generated.
When you save, by default, the code files will be stored in the
<workspace>/<schemename>/wlm-models/generated-code folder.
Figure 8-25 on page 215 shows the generated WLMDEMO_BY_OBJ.wlmsql
creating DB2 Workloads.
Although the Editors view allows you to add, modify, or remove the DB2 WLM
statements, we do not recommend that you modify the code directly, because
the modifications will not be captured in Design Studio. To capture the
modifications in Design Studio, you need to perform reverse engineering after
the workload is created in DB2.
214
Figure 8-26 on page 216 shows the AIX WLM class generated under
WLMDEMO_BY_OBJ.osclasses.
Note: Any operating system WLM entities that you set up using Design Studio
will not be automatically created on the target AIX machine. Users have to
manually copy generated operating system code to the AIX machine and run
with root authority.
Only DB2 WLM entities will be automatically created when you perform
Execute or Delta Execute from Design Studio.
215
216
The Create limits for database activities screen will then be presented, showing
five tabs; see Figure 8-28 on page 218.
217
218
3. Work Identities
You can use this tab to add a new DB2 WLM work identity, or to delete or
modify an existing work identity.
If there are no previous user-defined work identities created, only the default
workloads SYSDEFAULTUSERWORKLOAD and
SYSDEFAULTADMWORKLOAD, are listed.
To add a work identity, click Add and the Work Identity property view is
presented; see Figure 8-12 on page 203. You can identify the connection
attributes to be used in your workload. To view the description of a field,
left-click the field name.
The capitalized fields in the Work Identity panel match the attributes in the
DB2 CREATE WORKLOAD statement. The three authorization fields are for
granting workload execution authority.
In our case, we created a workload WI_PROD to manage application
dss.exe; see Figure 8-30. The workload can be used by everyone (public). We
selected the Work Types tab to proceed.
219
Figure 8-30 Creating work identities in Create limits for database activities
4. Work Types
You can create a work type to categorize database activities by activity
characteristics type such as Read, Write, DML, DDL, Call, Load and All. Then
you can manage each work type as a unit. By creating a mapping rule for a
database superclass, you can map a work type to the subclass where the
database activities execute.
Figure 8-31 shows the Create Work Type panel. You create a work type set to
contain and manage a group of work types. If no suitable work type set is
available, you can create one using Create New Work Type Set....
220
Figure 8-32 shows the Create New Work Type Set property view. In our
example, we created a Work type set WTS_ALL.
To define and associate a work type with a work type set, select the work type
set, enter the work type name (WT_ALL, in our example), select a work type,
and click OK; see Figure 8-33 on page 222.
221
You need to define the measurement properties for the work type. Work type
optionally can include estimates. In our example, we wanted to apply
WT_ALL regardless of the measurement, so we choose NONE as shown in
Figure 8-34.
The capitalized field options in the Work Type Set panel and Work Type panel
match the attributes in the DB2 CREATE WORK CLASS SET statement.
Figure 8-35 on page 223 shows one work type set is created. You can create
more type sets by following the same process. After completion, select the
Create Limits tab to continue.
222
Figure 8-35 Work Type Tab after creating work type set
Note: Work types in a work type set are ordered objects when work types
are evaluated. To specify the evaluation order of a work type in the work
type set, open the Work Types tab by selecting the work type set in the
Scheme view. Then select the work type and use the up and down arrows
to reposition the work type in the list. If you do not specify an evaluation
order, the order of the Work Types tab implies the evaluation order.
5. Create Limits
In the Create Limits tab, click Add and then select the type of limit that you
want to create; see Figure 8-36.
223
224
one type to control problem queries on the database. Figure 8-37 shows that
for domain Work Type, the required fields are Work Type and Condition.
To specify the work type that you want to limit, click <select a work type>
and a browse button shows in the field. Click the browse button to select the
list of work type sets you can choose from; see Figure 8-38.
225
Click <Create a condition> to specify the Condition for a work type that you
want to limit, and a browse button shows in the field; see Figure 8-39.
226
Click the browse button to create a Condition to define the limitation condition
on the work type domain and the action to take when the limit is exceeded;
see Figure 8-40 on page 227.
227
You can continue adding limits. When you are finished, click OK and the
Database panel will be presented, allowing you to associate the limits to a
work action set. Click the browse button to specify the work action set; see
Figure 8-42 on page 228.
After associating the work action, click OK. Design Studio creates a WLM
Scheme and returns you to the default Business Intelligence (BI) perspective.
228
In the BI perspective, Design Studio focuses you on the Editors panel and
presents the overview of the current project created. Figure 8-43 shows the
project we created, WLMDEMO_BY_OBJ, and its control rules.
229
Design Studio provides the facility to add control rules using the templates.
230
You can complete the fields in the Properties view for the new control rule; see
Figure 8-46.
When you create the Control Rule for Database using Design Studio, it
generates code that is equivalent to DB2 CREATE THRESHOLD ...FOR
DATABASE ACTIVITIES ....
231
Control rules can also be used for other tasks such as:
Force off idle connections after a specified time period.
Apply the control rule based on activity type
Stop activity that consumes excessive temporary space.
Allow one activity to take a higher share of resources than other activities.
For example, allow LOAD to use more temporary space than others.
Collect activity data only on higher cost queries.
232
The Create limits for the concurrent database activities main screen contains five
tabs: General, Superclasses, Work Identities, Work Types and Create Limits;
see Figure 8-48.
233
Figure 8-48 Create limits for concurrent database activities - Main screen
General
This is an informational tab. Select the Superclasses tab to continue.
Superclasses, Work Identities, and Work Type sets
Use the same process described in Controlling and sharing system
resources on page 200, to create superclasses, work identities, and work
type sets.
Create Limits
Use this tab (shown in Figure 8-49 on page 235) to create limits for
concurrent activities.
234
Figure 8-49 Create limits for concurrent database activities - Create Limits tab
Click Add and choose the type of limit you want to set, as shown in
Figure 8-50 on page 236.
235
Figure 8-50 Create limits for concurrent database activities - Create Limit options
236
Specify the work identity that is the source of the occurrence or activity.
Note: The help information can be turned on or off using the twist icon
on the top left corner on the Create Limits tab.
For our example, we selected Limit concurrent coordinator activities for
database to restrict concurrent instance of an activity. An entry is added to
with required fields opened (not greyed out). Design Studio presents a
browse button next to the field when you click the opened field; see
Figure 8-51.
237
In our example, the Create Condition panel presents where you can specify
concurrency control configuration; see Figure 8-52. To see the description of
a field, left-click the field name.
Note: Setting the value for the maximum number of connections allowed in
a queue to unbounded is not recommended. There might be problems if
you have limited the number of connections allowed for the database. In
this case, unbounded queues let the queued activities to use all of the
allowed connections, so unrelated but legitimate work might be locked out
unexpectedly.
After completing the Create Condition screen, click OK. This creates the
control rule for concurrency control for database activities, as shown in
Figure 8-53.
238
Figure 8-53 Create limits for Concurrent database activities showing Control Rule
You can add additional control rules by using the Add button. After all the
control rules are defined, click OK. Design Studio creates a WLM Scheme
and returns you to the default Business Intelligence (BI) perspective. The BI
Perspective is expanded to show the final output; see Figure 8-54.
Figure 8-54 Control Rule to limit concurrent coordinator activities for database - tree view
239
240
Click Next and the Workload Management Scheme Options panel will be
displayed, where you can define a work action set name. By default, it takes the
WLM scheme name you provided as the work action set name. In our case, we
kept the default work action set name and clicked Finish. The file name created
is the scheme name with .wlms under the default workspace defined.
In addition to the default work identities, Design Studio also shows you these
defaults:
Default super classes (SYSDEFAULTSYSTEMCLASS,
SYSDEFAULTUSERCLASS)
Default subclass under every superclass (SYSDEFAULTSUBCLASS)
Default histogram (SYSDEFAULTHISTOGRAM)
Design Studio creates the WLM scheme with only the default work identities, as
shown in Figure 8-56 on page 241. Therefore, you have to create all other
user-defined entities such as superclass, subclass, work identities, work type,
work type sets, control rules and mapping rules by using the tree view.
241
To create a new entity, right-click the object and select the option. We show here
the steps to create a new superclass. For example, right-click Superclasses and
select New Superclass, as shown in Figure 8-57.
You are required to enter a unique name in the New Superclass window and
provide additional information in the Properties view; see Figure 8-58.
242
After creating all the superclasses, subclasses, work identities, work type sets
and work types, control rules and mapping rules, validate the scheme by
Workload Management -> Validate. Use the Generate Code menu option to
generate DB2 statements for deployment.
Service superclass
Superclass
Service subclass
Subclass
Workload
Work identity
Work class
Work type
243
DB2 WLM threshold rules and enforcement criteria such as work action sets and
corresponding to Design Studio control and mapping rules are shown in
Table 8-3.
Table 8-3 Control rules mapping
DB2 WLM control criteria
244
3. In the Select Connection panel (Figure 8-60 on page 246), connect to the
database where the collection of information about the scheme exists by
using the existing connection, or create a new connection. We selected
Create a new connection.
245
4. Complete the Connections Parameters (Figure 8-61 on page 247) panel, and
click Finish.
246
5. Design Studio retrieves the information about the scheme from the database,
creates the new scheme, and creates a file for the scheme. The file name is
<WLM scheme name>.wlms. The output is shown in Figure 8-62 on
page 248.
Now, you can modify the scheme according to your specifications.
247
248
If you incur error and warning messages, correct the definitions as required and
then repeat the code generation procedure.
After the code generation process succeeds, you are ready to deploy the
scheme.
Note: During Workload Management -> Generate Code, if the database
does not contain any WLM Scheme, Design Studio will display an information
screen stating: No code was generated because the scheme is empty.
Design Studio provides two approaches to run the WLM scheme: Execute, and
Delta Execute.
Execution
The execution approach is a clean execution. When you execute a workload
management scheme, it begins by wiping off all the exiting WLM configuration on
the target and creating the entire scheme fresh in the target. Note, however, that
if the execution fails, then the settings for the WLM configuration that exist in the
database are lost.
We recommend using this option only when you want to create a fresh start.
To execute a workload management scheme:
1. With the workload management scheme open, select Workload
Management -> Execute.
2. In the Generated Code window, review the code that will be executed in the
database.
3. Select Execute in database, and click Next.
4. In the Execution Options window, specify any options and click Next.
5. In the Select Connection window, connect to the target database.
You can select Create a new connection, click Next, complete the
Connections Parameters window, and click Finish.
Or you can select Use an existing connection, select that connection,
and click Finish.
6. In the Execution Result panel, review the execution log information. You can
also save the execution log information.
Figure 8-63 shows the execution results panel using Execute.
249
Delta Execution
Delta Execution performs ALTER whenever possible, and performs CREATE or
DROP of WLM entities only when necessary. It performs reverse engineering on
the target database and determines the changes.
You can use the Delta Execute to alter the database or another workload
management scheme to make it identical to the current workload management
scheme.
Using Delta Execute, you can apply scheme settings to the database. Some of
the advantages of using Delta Execute are:
Each WLM statement has been committed.
Only one uncommitted WLM-exclusive SQL statement at a time is allowed
across all partitions. If an uncommitted WLM-exclusive SQL statement is
executing, subsequent WLM-exclusive SQL statements will wait until the
current WLM-exclusive SQL statement commits or rolls back.
If an error occurs during Delta Execution, Design Studio will not make any
changes in the database. Your database will be in the same state as before
the Delta Execution.
250
251
5. In the Generated Code window, select Execute in database and click Next.
6. In the Execution Options window (Figure 8-66 on page 252), specify any
options and click Next.
252
In the Execution Result window (Figure 8-67), verify the result and click
Finish.
253
3. Choose the .wlm files of the WLM scheme to be compared with; see
Figure 8-69.
254
255
256
Note: DB2 service classes cannot work with the AIX Workload Manager
inheritance feature. In Design Studio, inheritance attribute was not enabled by
default. If inheritance is enabled, the DB2 workload manager cannot change
the AIX workload management class of a thread using tagging.
This restriction makes any integration of DB2 Workload Manager and AIX
Workload Manager unusable. The DB2 data server cannot detect whether AIX
Workload Manager inheritance is enabled, and does not issue an error
message if inheritance is enabled.
257
5. In the New Operating System Subclass window, type a unique name and
click OK.
6. Define the properties of the operating system subclass by completing the
General tab of the Properties view; see Figure 8-74.
258
259
You also can create the operating system limits on the subclass level by
selecting the resource on the subclass level, as shown in Figure 8-76.
4. In the prompted window, enter a unique name for the limit and click OK.
5. Define the properties of the limit by completing the General tab of the
Properties view; see Figure 8-77 on page 261.
260
261
4. In the window, type a unique name for the share and click OK.
5. Define the properties of the system resource share by completing the General
tab of the Properties view; see Figure 8-79 on page 263.
262
263
264
2. In New Operating System Superclass Rule, type a unique name for the rule
and click OK.
3. Define the properties of the rule by completing the General tab of the
Properties view.
4. To associate the operating system superclass, select the
button for the
operating system service class and select the superclass you want.
Figure 8-82 shows that, in our case, we created aixHighLvl_rule and associated
it with operating system superclass AIXHighLevel.
265
266
The Generated Code Information window lists the files that are created and their
usage. If you click OK, Design Studio will automatically open the files generated
in the Editors view.
Any of three possible files can be generated:
DB2 command code file
This file is generated and listed in the message when DB2 workload
management entities exist in the scheme. The file is created with the Scheme
name and a .wlmsql extension (for example, WLMDB_REV.wlmsql).
Figure 8-84 shows the DB2 SQL generated by Design Studio.
Classes file
This file is generated and listed when operating system service classes exist
in the scheme. The file is created with the scheme name and .osclasses
extension; for example, WLMDB_REV.osclasses.
Figure 8-85 shows the sample output of the operating system class file.
267
Rules file
This file is generated and listed when process assignment rules for operating
system service classes exist in the scheme. The file is created with the
scheme name and .osrules extension; for example, WLMDB_REV.osrules.
Figure 8-86 on page 269 shows sample output of the operating systems rules
file.
268
Figure 8-86 Generated code sample for operating system rules file
269
270
Chapter 9.
271
Applications
Instance and database statistics
Configuration
Workload management
You can monitor your DB2 systems real time and historical performance
behavior using DB2 Performance Expert. DB2 Performance Expert (PE) uses the
DB2 snapshot and event monitor capabilities to capture the performance data,
and stores the data in DB2 tables on the PE server. You use the DB2
Performance Expert Client to view and work with the data.
Focus
This chapter discusses only the use of DB2 Performance Expert to monitor DB2
Workload Manager capabilities. To learn more about general usage of DB2
Performance Expert, consult the following sources:
DB2 Performance Expert product information page at ibm.com:
http://www-306.ibm.com/software/data/db2imstools/db2tools/db2pe/db2pe-mp.ht
ml
272
Consult your IBM sales representative for more information, or refer to the DB2
Performance Expert home page:
http://www-306.ibm.com/software/data/db2imstools/db2tools/db2pe/db2pe-mp.html
Install PE Server.
Install PE Server FixPack, if applicable.
Configure PE Server.
Install PE Client.
Configure PE Client.
There are no special DB2 Performance Expert setup steps for monitoring DB2 in
a multi-partition (DPF) environment, or for monitoring WLM. There are some
configuration settings you can modify for frequency of data collection, and they
are described in Viewing workload statistics and histograms on page 296.
For more technical information, as well as hints and tips for WLM monitoring with
PE, see DB2 Performance Expert technical information on page 303.
Note: At the time of writing, PE V3.1 was the latest version available, and
PE V3.1 Fixpack 1 (V3.1.1) was released. PE V3.1 Fixpack 1 has additional
features that enhance WLM monitoring and offer additional capabilities for
monitoring multi-partition (DPF) environments. We did not rewrite this whole
chapter to reflect the new changes, but have called out some enhancements
where appropriate.
Also note that some of the figures in this chapter may no longer match the
screen appearance in V3.1.1.
273
Monitoring applications
When you use DB2 Performance Expert to monitor the applications or
connections running on your system, you use the Application Summary and
Application Details views in the PE Client.
Application Summary
As shown in Figure 9-1, you can view various pieces of information about the
running applications in your system. This is called the Application Summary view.
The third column shows the Workload ID number. At a glance, then, you are able
to see what activities are running within which workloads. You can also filter, sort,
modify, and rearrange which columns appear in the Application Summary page.
274
Application Details
To view details about any one application, double-click the application row in the
Application Summary view, and a new window called Application Details will
open, as shown in Figure 9-2. You can look at the currently executing statement,
and even launch the DB2 Visual Explain. Some performance counters which are
especially relevant to workload management functions are the timerons and
cardinality estimates.
The Identification page of Application Details, shown in Figure 9-3, also shows
some information that can be useful in troubleshooting your workloads and
service classes. The workload ID value is in the top section under the Application
Information group heading. The fields named under the heading TP Monitor
client are the strings that can be set with the WLM_SET_CLIENT_INFO stored
procedure, or on the JDBC connection itself. An example of this is described in
3.3.2, Creating the workloads on page 57. In Figure 9-3 on page 276, however,
they were not set, so they appear as N/P (not present).
275
DPF considerations
DB2 Performance Expert provides different views of the work running on your
DPF system. If PE detects a multi-partition instance, you will have a drop-down
list at the top of the window, where you can select the different views. The views
are:
Individual partition - shows data for a single partition only.
GROUP view - show data from each partition.
(This is not related to the DB2 database partition group definitions.)
GLOBAL view - shows aggregated data from all partitions (uses GLOBAL
snapshot).
Note: With DB2 Performance Expert V3.1 Fixpack 1, you also have the option
of customizing the groups of partitions for monitoring. This is called a Partition
Set. The Partition Sets will also appear in the drop-down list.
276
In Figure 9-4, we see an example of the GROUP view of all applications, sorted
by the Total Sorts column, showing the most sorts at the top. The Group view is
useful for comparing performance counters between partitions at a glance. You
can display and sort different performance columns quickly see if there are
skews.
When you drill down to the Application Details in a DPF application, you can use
the Subsections page to view how a query is progressing. Figure 9-5 shows an
example.
277
Heavy-hitter tables
You can use the Statistics Details - Tables view to see which tables are being
accessed the most. In Figure 9-6, we see the data for only Partition 1, sorted by
Rows Read, and we can see the LINEITEM table is by far the most-read table.
278
279
Figure 9-7 Dynamic SQL - sorted by Average time per execution - Partition 1
280
Figure 9-8 Statistics Details - Buffer pool hit ratio - Group view
281
Most PE performance counters are collected from DB2 snapshots. The WLM
statistics, however, are collected only via the statistics event monitor and are
collected at a different interval than the snapshot counters. This is why you see
the time interval shown on the top of the WLM perflet - to let you know the
interval over which the statistics data were collected and that it may not match
282
the time stamp shown at the top right side of the window, which is controlled by a
different refresh rate.
In Figure 9-9, we can see the System Overview refresh rate has been set to
1 minute, and this is what controls the time stamp at the top right of the window.
The WLM collection interval is, however, specified elsewhere and we can tell it
was set to 5 minutes (10:17:27 AM - 10:22:21 AM).
We discuss how to configure the WLM collection interval in Monitoring
non-default workloads on page 294.
By watching the Workload KPIs, you can always have a current view of which
workloads are active and busy. If you need to investigate more about the
workloads, you can look at the Workload Management screens in PE.
The first screen that appears lists each monitored database, with counts of the
various WLM objects defined in the database. An example is shown in
Figure 9-11. In our lab setup, we are only monitoring one database in the
instance. To drill down to more details for the WLMDB, we double-click the
WLMDB.
283
Now we will look at the same WLM definitions as described for the mixed
workload in 5.3, Manage the work on page 126. Here we have one top-level
service class with several subclasses and workloads underneath.
The definitions for the mixed workload are shown in Figure 9-12. When you
select a Service Class in the upper part of the screen, its associated subclasses
are highlighted in the lower part of the screen. In our mixed workload, we have
several subclasses that all belong to the HIGHLVL service class.
The columns displayed in the definition view can be rearranged or sorted. In our
case we have arranged the subclasses to show the common attributes such as
the values that were specified on the COLLECT AGGREGATE clause. It is an
easy way to see all our definitions at a glance.
284
Next we want to view the definitions for the workloads, so we select Workloads
from the navigation tree on the left side of the window. In Figure 9-13, we can see
all the workloads for the WLMDB database, sorted by the evaluation order. In
Chapter 5, WLM sample scenarios - mixed OLTP and DSS environment on
page 123, the OLTP workload was added and placed ahead of the other
workloads in the evaluation order, and indeed that is what we see here.
285
To view detail about any WLM definition, double-click it. Figure 9-14 shows an
example detail page for the WL_PROD_QRY workload.
286
We can use Performance Expert history mode to see what the definitions were in
the past.
287
counts that are available. The manual method is described in Monitoring the
default WLM environment on page 45, where you can write a query to get
information. In PE, you can open the WLM Statistics page. Figure 9-15 shows
using PE to view the high watermark, or peak, connections within the default
service classes.
The same screen also displays the service subclasses. When you select the
superclass, the associated subclass (or subclasses) will be highlighted.
To see more detail about the subclass statistics, double-click its entry on the
table in the lower portion of the screen. This launches a new tab, as shown in
Figure 9-16. Here we see the same information as on the previous screen, but for
the single subclass. Because we have not enabled any of the collection
parameters on the service classes, many fields are reported as -1, meaning the
data is not present.
288
Notice also that we also have a section named Histograms. In this case there is
no histogram data because no collection has been activated yet. We see more
about histograms in Viewing workload statistics and histograms on page 296.
You can view default workload statistics by selecting Workload from the
navigation tree on the Workload Management Details page, as shown in
Figure 9-17.
289
DPF Mode
When you are using a DPF system, you have other options for viewing the
statistics. We look at a default DPF system where, as in the previous examples,
we have not configured any WLM settings. In Figure 9-18, we see the same type
of information as we saw in Figure 9-15 on page 288, but instead this is showing
counts only for the designated partition - PART0.
290
You can choose other views from the drop-down list. Next, we look at the
GLOBAL view, shown in Figure 9-19. We selected GLOBAL from the list and in
this case, the counts did not change.
291
Figure 9-19 WLM default Service Class statistics - DPF- GLOBAL view
In Figure 9-20, we see the results of choosing the GROUP option from the
drop-down list box. In this view, we can see the key counts for each partition. You
cannot see all the counts for all partitions on this page, so the most critical ones
are shown here.
292
Figure 9-20 WLM default Service Class statistics - DPF - GROUP view
Double-click a Service Class to view the counts for all partitions for that one
service class, as shown in Figure 9-21.
293
Figure 9-21 WLM default Service Class statistics - DPF - GROUP details view
294
its own data collection. However, we did not create the BASIC_MON event
monitor as described in the earlier chapters.
In the PE monitored instance properties, we define the collection interval to be
5 minutes for both workload definitions and workload statistics, as shown in
Figure 9-22.
Note: We chose a 5-minute interval simply to hasten data collection for the
purposes of demonstration. In a real-life scenario, you would choose a
longer interval for both WLM statistics and WLM definition.
Figure 9-22 Setting the WLM statistics collection interval in DB2 Performance Expert
That is all the setup that is required. PE will create a statistics event monitor in
the monitored database, and it will handle the data retrieval. You can read more
about the technical details in DB2 Performance Expert technical information on
page 303.
The following section contains examples of screens where you can quickly see
the WLM statistics without writing the queries as described in earlier chapters of
this book.
295
296
The PROD_RPT service class is the only one with statistics at the moment, so
we want to drill down to see more information about that one. We double-click
the HIGHLVL.PROD_RPT subclass on the lower part of the window. This opens
up another tab, as we see in Figure 9-25. This is more or less the same
information as on the summary page, but you can view it for just one subclass.
The lower area of the window references some Histogram statistics that are
available.
297
298
Figure 9-26 WLM Histogram view for PROD_RPT Request execution time
299
versions of PE, however, you can view many of the DB2 and operating system
counters from the GUI screen, in the form of a trend analysis graph.
To access the PWH trend analysis, right-click the performance counter you are
interested in, which brings up the context menu. Not all performance counters
can be viewed this way, so if the context menu item is disabled (grayed out), it
means that the counter is not available. If it is not grayed out, select the item as
shown in Figure 9-27. In this case we are looking at a WLM statistic - the peak
value for cost estimate (timerons) for the HIGHLVL.ADMINS service class.
When you launch the PWH trend analysis, a new tab opens and a graph is
displayed. The graph shows the actual values (in blue), but also calculates a
historical trend (dark gray) based on those values, and a future projection (light
gray) of the values. In Figure 9-28, we see the trend for the cost estimate WLM
300
counter. You can adjust the view to show longer or shorter time ranges up to one
year.
These trend charts can be helpful in enabling you to quickly recognize when
something may be trending out of good performance, or that perhaps a
temporary spike has occurred that you can investigate further. Along with the
WLM counters we see here, the trend charts are available for operating system
and DB2 statistics counters, such as paging space usage, buffer pool hit ratios,
table pages used, rows read and so on.
301
In Figure 9-29, we see a list of the predefined queries that come with PE. We are
interested in the WLM-related queries. In this example we execute the query for
WLM Workload Definitions.
To execute a query as-is, right-click the query and select EXECUTE from the
context menu. In many cases, you might want to modify the query slightly to suit
your own needs, but we do not explore that in this section.
Note: To see more examples showing how to use the DB2 Performance
Expert Performance Warehouse queries and reports, refer to the IBM
Redbooks publication DB2 Performance Expert for Multiplatforms V2.2,
SG24-6470.
After executing the query, the results are displayed in the PE window as shown
in Figure 9-30. You can save the results to a text file, or view them in a browser,
where you could also save the HTML output.
302
303
Notice that there is another event monitor active on this instance that is called
VIOLATIONS. This is also a WLM-related event monitor but it is not for Statistics,
it is for the workload threshold violations so it is of the Threshold Violations type.
The PE event monitor can coexist with activity and threshold violation event
monitors you may create manually.
304
305
Figure 9-33 PE Table detail for non-PE histogram event monitor table
In our case, we intentionally did not clear out this table because we were
conducting tests, but if you look at Figure 9-34, which is a PWH trend chart of the
Data Object Pages counter, you can see how the table has grown over time and
would continue to do so unless you took action.
306
Compare this to the PE event monitor table size, as shown in Figure 9-35, where
you can see the table is much less volatile in its size.
307
PE will create and activate the event monitor when you enable history collection
for WLM. This is enabled by default, so by default the event monitor and the
associated tables are created when you start the PE server.
308
The rest of the DB2 performance data is collected using snapshots, which are
controlled by the other interval values on the properties page. These are
independent from the WLM collection times.
309
and time of the data on the screen by looking at the upper right portion of the
screen. (This is true for all PE screens, by the way, and not just WLM data.)
If you are already familiar with PEs other features, this WLM behavior will seem
quite strange. If you consider, however, the underlying architecture of how PE
captures, stores, and presents the information to you in the GUI, then you will get
more comfortable with PE.
310
311
312
10
Chapter 10.
Administering a DB2
workload management
environment
This chapter discusses the key points to check in administering a DB2 workload
management environment. As you gain familiarity with how DB2 Workload
Manager (WLM) works, you will be creating a number of workload management
objects, and collecting baseline data and statistics for analysis. After enabling the
WLM controls and fine-tuning the WLM monitoring, you will have a working WLM
environment that meets your needs. After you migrate all of your WLM settings to
full production, you need to periodically purge old data, back up the WLM
settings, and take note of the tools needed in problem diagnosis.
We discuss the following topics in this chapter:
WLM logs and maintenance
WLM problem diagnosis
WLM backup and recovery
WLM authorization
313
314
Does the problem in WLM occur by itself, or does it occur when other DB2
problems occur?
Review the diagnostic logs, db2diag.log, and the administration notification
log, < DB2 instance name>.nfy, to determine if the WLM problem is related to
a DB2 problem, and isolate the source.
Is the problem related to a WLM workload or workload occurrence?
You need to gather the following information about workloads:
Get the list of workload occurrences using the
WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURENCES table
function.
Get the identifier for the workload and workload occurrence using the
WLM_GET_WORKLOAD_OCCURENCE_ACTIVITIES table function.
Get the list of all activities and requests running under a workload
occurrence using the
WLM_GET_WORKLOAD_OCCURRENCE_ACTIVITIES table function.
Get the workload information in memory by using the db2pd -db
<database name> -workloads command.
Is the problem related to a WLM service class using more than a fair share of
agents?
One possible cause of a problem is that a data server resource, such as an
agent, is overutilized by a group of users or an application. A service class
may be using more than its fair share of agents.
Determine the service class that is overutilizing resources and take action to
limit the resources being used by the service class.
Example 10-1 illustrates the use of the
WLM_GET_SERVICE_CLASS_AGENTS table function to determine how
many agents are working for each service class.
Example 10-1 Determine how many agents are working for each service class
SELECT SUBSTR(agents.service_superclass_name,1,19) AS
superclass_name,
SUBSTR(agents.service_subclass_name,1,19) AS subclass_name,
COUNT(*) AS agent_count
FROM TABLE(WLM_GET_SERVICE_CLASS_AGENTS('', '', CAST(NULL AS
BIGINT), -2)) AS agents
WHERE agent_state = 'ACTIVE'
GROUP BY service_superclass_name, service_subclass_name
ORDER BY service_superclass_name, service_subclass_name
315
316
Is the problem related to not seeing the expected behavior when using AIX
WLM with DB2 WLM?
If you are not seeing the desired behavior, you may need to adjust the AIX
WLM configuration. The AIX WLM configuration can be reviewed with the
help of AIX WLM tools such as wlmstat, wlmmon. and wlmperf.
In summary, WLM problem diagnosis requires the use of DB2 diagnostic logs,
the WLM table functions such as WLM_GET_SERVICE_CLASS_AGENTS,
WLM _GET_SERVICE_CLASS_STATS, and the db2pd utility, to obtain the
necessary information about what is happening in the system.
Example 10-3 shows how to invoke the db2pd options for WLM.
Example 10-3 Using the db2pd utility to get WLM information
db2pd -db WLMDB -workloads -workactionsets -workclasssets
DBAccess
0
0
317
0x07700000AB7B0250 5
9223372036854775806
0x07700000AB7B0340 6
9223372036854775806
0x07700000AB7B0430 7
9223372036854775806
0x07700000AB7B0518 1
9223372036854775806
0x07700000AB7B05E8 2
9223372036854775806
0
0
0
0
0
WL_PROD_RPT
ALLOW
9223372036854775806 18
WL_PROD_QRY
ALLOW
9223372036854775806 19
WL_ADMIN
ALLOW
9223372036854775806 16
SYSDEFAULTUSERWORKLOAD
ALLOW
9223372036854775806 13
SYSDEFAULTADMWORKLOAD
ALLOW
9223372036854775806 13
0
0
0
0
0
...
Only the DB2 instance owner can run the db2pd utility. If you are not the DB2
instance owner, you will get the following error message:
Unable to attach to database manager on partition 0.
Please ensure the following are true:
- db2start has been run for the partition.
- db2pd is being run on the same physical machine as the
partition.
- DB2NODE environment variable setting is correct for the
partition
or db2pd -dbp setting is correct for the partition.
This saves all the CREATE and ALTER statements for WLM objects, including
all WLM CREATE event monitor statement, as well as GRANT USAGE ON
WORKLOAD statements.
318
USAGE
USAGE
USAGE
USAGE
ON
ON
ON
ON
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
campaign
campaign
campaign
campaign
TO
TO
TO
TO
USER bill;
GROUP sales;
ROLE salesperson;
PUBLIC;
319
You can use the REVOKE USAGE command to revoke USAGE from a user,
group, or role from a workload. However, the REVOKE USAGE command does
not work on the SYSDEFAULTADMWORKLOAD.
Example 10-6 shows how the USAGE privileges granted in Example 10-5 can be
revoked.
Example 10-6 Example of the REVOKE USAGE command
REVOKE
REVOKE
REVOKE
REVOKE
320
USAGE
USAGE
USAGE
USAGE
ON
ON
ON
ON
WORKLOAD
WORKLOAD
WORKLOAD
WORKLOAD
campaign
campaign
CAMPAIGN
campaign
FROM
FROM
FROM
FROM
USER bill;
GROUP sales;
ROLE salesperson;
PUBLIC;
11
Chapter 11.
321
322
In a QP environment, the life cycle of a query looks something like the following:
Queries requests are submitted to run on the server.
The query is intercepted on the server and QP determines if it is a query to be
managed or bypassed. Managing queries requires some overhead, so it is
often a good idea to minimize the overhead by selecting a set of queries
(such as really short queries or queries from a given application) to bypass
QP altogether.
Information about each managed query is written to a QP control table. The
query attributes (submitter, estimated cost) are evaluated and a decision is
made on whether to run the query now, queue the query until other work
completes, or to put the query in a hold state (which is basically an error
condition saying the query looks like it is too large to run at all, and needs to
be looked at and possibly scheduled to run at a more appropriate time).
After QP decides a query can be run, it is released to the data server to
execute along with everything else on the system.
QP is not aware of the query until the execution phase is complete and QP
updates that query's control table entry with statistics about the execution
results (for example, execution time, time queued, error code, and so on).
323
are still estimateswhich means they could be wrong. For example, perhaps
RUNSTATS has not been run for a while (the optimizer uses statistics to choose
an optimal access plan, so they should be kept up to date).
This is where the DB2 Governor nicely complements Query Patroller with its
reactive approach to workload management. After QP lets the query loose to
execute, the DB2 Governor then watches for certain thresholds during the
execution that can result in events to be triggered.
The thresholds include:
324
11.2 Coexistence
Switching from a workload management solution using QP and the Governor to
one using the WLM features has many benefits, but it is not feasible to assume
that this can happen without some thought and effort. We discuss what the
325
environment looks like in DB2 V9.5 and then discuss how to approach the task of
moving to a WLM solution.
Note: To dispel any misconceptions, keep in mind that although QP and the
Governor may not be the future strategic direction for workload management
in DB2, they are still fully supported in DB2 9.5 and are functionally equivalent
to previous versions.
When you first install DB2 9.5, there is a default workload created to identify all
the user database activities and map them to a default user service class. The
default user service class is the execution environment where all database user
activities will run. There are other database activities, like prefetching or some
health monitoring activities, that would be mapped to either a system or
maintenance service class. This discussion does not include those activities.
QP and the Governor only intercept and manage queries assigned and
executing in the default user service class. In a vanilla install or migration, this
includes all database activities, so the life cycle of a query essentially stays the
same except that before QP gets to take a look at the query, it is first assigned to
the default service class and the Governor will only act on that same set of
activities.
Figure 11-2 illustrates the Query Patroller in a default WLM environment.
326
If there are workloads defined to route user activities to service classes other
than the default use class, Query Patroller and the Governor will not be able to
manage the activities, because they will bypass those tools completely.
327
328
Let us assume that the business goals for the workload are understood. The
following sections run through some of the Query Patroller and Governor
configuration options and some points to ponder when considering how they may
map to a WLM configuration.
Identification
Query Patroller identifies and classifies database activities in two ways. The first
way is based on a range of estimated query cost (for example, group work by
small-, medium-, or large-sized queries). The second way is based on the
user ID or group ID that submitted the query. There is also an implicit
classification of work with QP simply because QP can only intercept DML (that is,
all DDL, utilities, and so on will never appear on the QP radar).
DB2 WLM identifies and classifies work in many more ways. They can be
grouped by the following connection attributes:
Application name
System user
Session user
A group of session users
A role of session users
Client user ID
Client application name
Client workstation name
Client accounting string
These activities can be further classified based on the type of activities, such as:
DML
DDL
LOAD utility
READ statements
WRITE statements
CALL (for stored procedures)
Management
In this section, we discuss the major QP management functions and their
equivalents in DB2 WLM, and provide migration tips.
329
Concurrency threshold
Query Patroller workload management relies primarily on concurrency
thresholds to limit the number of queries that can run at a given time for a given
classification. The premise is that queuing some of the activities on a data server
that is running over capacity will prevent resource contention that can result in
costly paging and thrashing. Indeed, there have been some rather dramatic
improvements in workload throughput for some customers.
The actual concurrency threshold value, however, can be quite difficult to
determine. How do you really know when you start to encounter resource
contention? For example, is it when a user submits more than five queries? Does
it depend on the time of day? Does it depend on the volume of work?
The process of determining the threshold value often ends up being subjective,
and the result is a generalization of the management of the workload across
users. This generalization has to be lenient enough to avoid imposing on
productivity throughout the day, when there are varying volumes of database
activity. Even so, there is still a fair amount of trial and error involved in arriving at
that configuration.
Concurrency thresholds can be useful, though, and they are available through
DB2 WLM. But instead of jumping to concurrency thresholds immediately,
consider using the resource controls available for a service class. Using these,
you can give database activities relative priorities for CPU and prefetching (I/O).
Using AIX WLM, you can even configure a more granular level of CPU resource
control to make available a certain percentage of the processing power for the
service class.
Migration action: Do not use concurrency thresholds as the first option for
workload management. Instead, look at controlling the CPU and prefetch
priority options on service classes. If you are on the AIX platform, consider
using AIX WLM for a more granular control of CPU.
Query classes
Query classes are another form of concurrency control, and one of the most
powerful management options inside of QP. The concept behind query classes is
to allow the query requests to be grouped by the estimated cost of the query.
There are often three groups: very short transaction queries; very large report
generation queries; and general maintenance or ad hoc queries that fall
somewhere in the middle. Each group, or query class, can be configured to limit
the maximum number of queries that can run inside that group at a time.
330
QP is most effective when you set a low maximum concurrency level for the
class of large queries. This prevents large, resource-intensive queries from
consuming a disproportionate amount of resources, which would result in slower,
unpredictable response times for the transaction query class.
The same issues of actually trying to determine a proper configuration for query
classes also exist for query classes. However, not only do you have to determine
a suitable maximum concurrency, but also you have to figure out what defines a
small, medium and large query. Remember, QP relies heavily on cost estimates
from the optimizer to define the range of cost for each query class. That estimate
is very sensitive to statistics on the server and has a reputation of occasionally
being inaccurate (which could result in a query being assigned to the wrong
query class and hearing complaints from users about a normally short-running
query taking much longer because it was assigned to the wrong class).
It is possible to configure DB2 WLM to have the equivalent to query classes. You
would use work classes and work action sets to identify the DML work, and then
set up thresholds on the work action set based on the range of query cost.
This is a prime example of stepping back and reexamining the business goals.
Typically, we find that query classes are used to maximize throughput by limiting
the longer-running queries. When you think about it, however, these different
types of queries rarely come from the same application.
For example, short queries could be coming from an application executing mass
transactions, OLTP, and even ETL activity. Long-running queries might be heavy
report generation applications. So, why not create a workload for the applications
executing the short transactions, and another workload for the applications
driving the heavy reports, and then map the work to separate service classes?
In this way you can control the resources for each service class where you can
keep the large queries throttled back by limiting CPU or I/O, or both.
Concurrency thresholds are still available on a service class, so you can continue
to limit the number of activities for an application to 5.
Migration action: Initially, do not try to implement a query class-like
environment in DB2 WLM. Instead, pull database activities out into service
classes based on the source attributes and control resource consumption
(and possibly concurrency) for the service class.
Cost threshold
Cost thresholds are set in Query Patroller to identify queries that are either
estimated to be quite small or very large.
331
332
Bypass options
A number of bypass options were introduced into Query Patroller in order to
minimize the overhead of the Query Patroller tool itself. Because each managed
query requires communication with the Query Patroller server and an update to
the QP control tables, it is best to set up QP to concentrate on the subset of
queries that have the most dramatic affect on the performance of the data server
as a whole.
Typically, queries lower than a set minimum estimated cost bypass QP, along
with some applications that have a fixed and known workload (for example, batch
ETL scripts).
Queries and applications can bypass QP by either setting the minimum cost to
manage in the submitter profile, the Applications to bypass settings in the QP
system properties, or by setting the DB2_QP_BYPASS_APPLICATIONS,
DB2_QP_BYPASS_USERS, or DB2_QP_BYPASS_COST registry variables on
the data server itself.
DB2 WLM is integrated into the DB2 engine and has no separate server
application (like the QP server). It also does not (by default) write individual
records of activity details to a table. So, WLM does not have the overhead issues
of QP, and no option to bypass WLM is provided. (It is also a fundamental
architectural point to have all database activities run in a service class.)
Migration action: There is no migration action. There is no need for a
mechanism to allow database activities to bypass WLM.
333
The problem is that QP (and DB2, for that matter) is only aware of the session
user ID that connected to the database, which is not the client user ID. This
makes it impossible to explicitly manage query workloads based on the client
submitter.
For example, suppose user JOE is using a vendor application to build a report.
JOE connects to reportapp.exe with a user ID 'JOE'. The vendor application
determines JOE is permitted to run the report, but it uses a DB2 connection from
its connection pool that connected with the user ID 'VENDORID' to avoid having
to establish and maintain a new connection for the 'JOE' user ID. QP considers
the submitter of the report query to be 'VENDORID' because the user 'JOE' is
never flowed to the data server. Therefore, there is no way to control Joe's query
activity, that is, not without also controlling every other user who is using the
connection from the connection pool.
In contrast, DB2 WLM has the client attributes available for proper identification
and management of queries. The application at the middle tier could either make
a sqleseti API call or wlm_set_client_info stored procedure call to set one of the
client attributes before it issues the SQL.
In this example, even though the connection is established using the
'VENDORID' session ID, the vendor application can call the sqleseti before the
query is run to provide data for the report and set the CURRENT
CLIENT_USERID to 'JOE' on the connection. JOE's database activity could then
be controlled by limiting this users resource consumption, or by setting
thresholds on the requests.
After a client attribute is set on the connection, it can then be used to identify
database activities that are coming from the middle tier based on the actual client
attributes.
Migration action: Use the sqleseti API to set client attributes to handle
connection pooling in a 3-tier application environment.
334
335
336
TRACK_QUERY_INFO Column
USER_ID
APPLICATION
CLIENT_USER_ID
CLIENT_ACCOUNT_ID
TRACK_QUERY_INFO Column
CLIENT_APPLICATION
CLIENT_WORKSTATION
Ideally, you would be able to create new workloads to isolate the database
activities based on the analysis of the connection attribute information. Note that
after those workload occurrences are assigned to a service class, Query
Patroller will no longer be aware of those queries.
Figure 11-3 illustrates how the workload management environment would look
after you start isolating activities based on the QP history.
337
There are a few other columns in the TRCK_QUERY_INFO control table that are
of interest, as well. These columns provide information on the type and
distribution of the database requests; see Table 11-3.
Table 11-3 TRACK_QUERY_INFO columns that map to other WLM functions
338
TRACK_QUERY_INFO column
TYPE
TRACK_QUERY_INFO column
EXECUTION_TIME_SECONDS,
EXECUTION_TIME_MILLISECONDS
ESTIMATED_COST
339
340
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this book.
IBM Redbooks
For information about ordering these publications, see How to get IBM
Redbooks on page 344. Note that some of the documents referenced here may
be available in softcopy only.
AIX 5L Workload Manager (WLM), SG24-5977
DB2 Performance Expert for Multiplatforms V2.2, SG24-6470
Leveraging DB2 Data Warehouse Edition for Business Intelligence,
SG24-7274
Other publications
These publications are also relevant as further information sources:
341
IBM - DB2 9
What's New, SC10-4253
Administration Guide: Implementation, SC10-4221
Administration Guide: Planning, SC10-4223
342
Related publications
343
Online resources
These Web sites are also relevant as further information sources:
DB2 Information Center
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp
Database and Information Management home page
http://www.ibm.com/software/data/
DB2 Universal Database home page
http://www.ibm.com/software/data/db2/udb/
DB2 Technical Support
http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/
index.d2w/report
DB2 online library
http://www.ibm.com/db2/library
344
Related publications
345
346
Index
A
act_total 108
activity 18
activity estimated cost histogram 109
activity event monitor group values
ACTIVITY 94
ACTIVITYSTMT 94
ACTIVITYVALS 94
CONTROL 94
activity execution time histogram 109
activity inter-arrival time histogram 109
activity lifetime histogram 109
activity queue time histogram 109
activity thresholds 15
administration notification 314
administrative view 80
agent priority 199
aggregate thresholdan 15
aggregated data 276
analytic application development 187
application name 204
application row 275
attribute 203
authority 193
authorization 313
automatic classification 147
automatic save 194
average activity lifetime 83
B
bandwidth 144, 316
BI 8
BI perspective 192
browse button 209
buffer pools 278
business intelligence 8
C
cardinality 275
catalog table 43
catalog table space 318
class name 147
D
data element 188
data mining 187188
347
F
flat mapping 154
formatted output 112
framework 188
function parameter 76, 83
G
generate code 214
global domain 17
global enforcement scope 17
grid view 195
H
hardmax 147
hierarchy 188
high watermark 288
histogram 29
histogram chart 298
historical monitoring 93
historical performance 272
history mode 299
I
I/O 8
identify the work 50
inheritance 146
in-memory statistics 314
installation and ocnfiguriation 273
integrated development environments 188
iostat 167
L
E
Eclipse platform 188
editor 193
enforcement scope 17
evaluation order 213
event monitor 93, 272
event monitor types
activities 27
statistics 27
threshold 27
executing statement 275
execution environment 4
execution limit 199
explain.ddl 103
348
lock-wait 80
logical work grouping 11
longest-running statements 279
long-term performance data 301
M
manage the work 50
maximum percentage 147
memory page 144
memory set 317
methodology 197
monitor switch 80
monitor the work 51
most-read table 278
multi-partition 273
N
navigation tree 289
nmon 148, 167
notification log 315
O
object definitions 318
Online Analytical Processing (OLAP) 9
Online Transaction Processing (OLTP) 9
Online Transaction Processing (OTP) 9
open source 188
open source community 188
operating system 143
optimizer 322
outbound correlator 162
R
reactive threshold 18
Redbooks Web site 344
Contact us xiii
refresh rate 283
relationship 208
repository 190
request execution time histogram 109
request_exec_time_avg 109
resource allocation 5
resource consumption 316
resource contention 5
Resource set 146
resource-intensive activity 4
RESTRICT option 319
reverse engineering 198
rows_returned_top 109
runtime environment 188
runtimes 188
P
paging space 301
partitions 280
PE performance database 299
perflets 282
performance 50
performance counter 300
performance counters 275, 282
performance data 272
plug-in 188
predefined limit 14
predictive 18
predictive governing tool 322
predictive threshold 18
prefetch priority 319
privilege 14, 193
problem diagnosis 313, 317
Properties view 193
pruning event monitor files or tables 314
ps monitoring tool 148
Q
query attributes 323
queue_assignments_total 108
queue_size_top 108
queue_time_total 108
queueing boundary 17
queueing threshold 17
S
scalable data warehouse 187
scope 16
service class 89
service classes 275
service level agreement 11
SET EVENT MONITOR STATE 96
shared subclass 146
shared superclass 144
snapshot 86, 272, 299
snapshot counters 282
sofmax 147
SQL 13
sqleseti 334
statement 214
statement cache 279
statistics collection 314
statistics event monitor group values
CONTROL 94
HISTOGRAMBIN 94
QSTATS 94
SCSTATS 94
WCSTATS 94
WLSTATS 94
stored procedures 18
subclass 297
summary statistics 83
superclass 190
Index
349
system administration 14
system resources 199
system superclass 144
system user 204
T
table spaces 278
tag 148
target database 269
target object 97
temp_tablespace_top 109
threshold 1415
threshold boundary 17
threshold domain 16
threshold queue 28
threshold violation 95, 104
threshold violations 304
Thresholds 8
tier level 146
time stamp 283
timerons 275
topas 148
transactional queries 325
tree structure 191
tree view 195
trehshold vioation event monitor group values
CONTROL 94
THRESHOLDVIOLATIONS 94
trend analysis 300
troubleshooting 275
U
unclassified superclass 145
unmanaged superclass 145
USAGE privilege 319
utility 8
V
validate 213
validation setting 213
Visual Explain 275
vmstat 167
volume group 171
W
warehouse management 187
watermark 28
350
wlo_completed_total 108
work action 95
work action set 8, 18
work class 8, 18
work class set 18
work identities 196
work type 18, 196
work type set 196
work types
ALL 18
CALL 18
DDL 18
DML 18
LOAD 18
READ 18
WRITE 18
Workload 8
workload 12
workload assignment 14
workload capture level
default 98
detailed 98
detailed with input data values 98
workload definition 14, 16
workload management scheme 190, 194
workload occurrence 14, 17, 76
workload privilege 24
workloads 275
workspace 190
Index
351
352
(0.5 spine)
0.475<->0.875
250 <-> 459 pages
Back cover
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
ISBN 0738485381