Outline

• Service Level Agreements
• Quiz
• WLM

Introduction

• Last Thursday, we finished talking about various attachment facilities of external applications with DB2.
• These included TSO, DSN, CAF, RRSAF, CICS, IMS, and DDF.
• Today, we are going to look at the Workload Manager.

The Setting in Which a Workload Manager Might be Useful

• In the real world, more than one application runs on a server.
• Many of these applications are critical to the success of business.
• Each application has its own performance target.
• We would like our system as a whole to be able to provide enough performance to guarantee these targets.

Service Level Agreement

• To make the notion of an application's performance targets more precise, we introduce the concept of a Service Level Agreement (SLA).
• An SLA is a contract that objectively describes:
  • Average transaction response time for network, I/O, CPU, or total
  • Distribution of response times (for example, 90% Time Sharing Option (TSO) trivial at less than 0.2 of a second)
  • Throughput
  • System availability (percentage of time that the system is available to users)
  • System load

Example SLA

Here is an SLA for ABC application:

• Ninety-five percent of all the data entry transactions must have an average response time less than 0.3 seconds.
• This service level must be kept during the time frame between 08:00 -- 17:00 of the working days.
• The application ABC has to be available for 96% of the service hours.

Quiz

Which of the following statements is true?

1. RACF is part of the DB2 and it is used for security.
2. A DB2 thread is a set of internal control blocks which DB2 uses to track a user's work.
3. Both the Call Attachment Facility and Resource Recovery Services Attachment Facility support the ability to SIGNON.

Workload Manager (WLM)

• The purpose of the WLM is to manage workloads to meet SLAs.
• A user (installation) classifies the work running on a z/OS operating system into distinct service classes. Each class defines goals that express the expectation of how the work should be performed.
• The WLM uses these goal definitions to manage the work across all systems of a Sysplex environment.
• To do this, it looks at how much "work" is running on the system, how much time each piece of work will take, and where contentions of resources might be occurring.

How much time each piece of work will take...

There are different ways to measure this.

• Response Time -- (usually average response time) the time on average the work needs to fulfill its task
• Percentile response time -- the percentage of all work requests that must end within a given time.
• Execution velocity -- this is used to capture the time that certain operations will take that are not easily defined in terms of transactions. The system cannot directly measure the response time of these resources so it collects information such as delay and so on for these kinds of work. The speed/execution velocity in the system is then expressed by the acceptable amount of delay for the work when it executes. This is given as a number between 0, bad, and 100, good.

Service Classes

We said a couple slides back that an installation classifies its work into service classes. Let's look at such classes in more detail...

• A service class is a group of work within a workload with similar performance characteristics.
• A service class always has the following two parameters: (1) importance and (2) performance goal. The latter consists of a response time, velocity, or discretionary value. Discretionary means no specific performance goal.
• A service class might also specify attributes of the following three types: Resource group, CPU Critical, or Storage Critical.
• z/OS has three system-provided service classes:
  • SYSTEM -- Used as the default service class for certain system address spaces. It does not have a goal.
  • SYSSTC -- The default service class for system tasks and privileged address spaces. It does not have a goal.
  • SYSOTHER -- As default service class for non-STC address spaces when no classification rules exists for the subsystem type. It is assigned a discretionary goal.

Example of WLM

• The installation must categorize the incoming work to the system using classification rules.
• Classification rules are the filters that WLM uses to associate a transaction's external properties, also called work qualifiers (such as LU name or user ID), with a goal.
• Some example work qualifiers are: Subsystem type, LU name/netid, Transaction name/job name, user ID, DB2 qualifiers such as package name

DB2 and WLM

• For the DB2 address spaces, the velocity goal is the most important.
• The following service classes are used for non-DBMS address spaces: SYSSTC is used for VTAM and TCP/IP address spaces and IRLM address space (IRLMPROC)
• Then for the DB2 address spaces such as MSTR, DBM1, DIST, an installation-defined service class with a high velocity goal is set.

WLM Buffer Pool Management

• WLM manages DB2 buffer pools when it is managing other storage resources
• DB2 can efficiently manage the size of its buffer pools by taking advantage of recommendations from WLM regarding increases or decreases in buffer pool size

How DB2 assigns I/O priorities

• DB2 informs z/OS about which address space's priority is to be associated with a particular I/O request
• WLM handles the management of the request.
• The main distinction DB2 uses in determining address space is where the operation is local or DDF.
• If it is local and a read the I/O will be given the Application Address Space Priority. For DDF reads, enclave priority is used (enclaves will be discussed in a moment).

DB2 and WLM in a Distributed Environment

• An enclave is an entity that encapsulates the execution units. It is close to the user view of a transaction.
• When a DB2 request (transaction) is received by DDF from the network, the DDF creates an enclave to process the SQL request using a DB2 thread.
• The thread executes DB2 code in cross-memory mode under the enclave priority.
• This is priority that the WLM will use.

Threads in a Distributed Environment

• Database access threads are created to access data at a DB2 server on behalf of a requester using either DRDA or DB2 private protocol.
• A database access thread is created when an SQL request is received from the requester.
• Allied threads perform work at a requesting DB2.
• Database access threads have two modes of processing: ACTIVE MODE and INACTIVE MODE.
• Active mode access threads are always active from initial creation to termination.
• Inactive mode access threads can either be active or pooled.
• When a database access thread in INACTIVE MODE is active, it processes requests from client connections within units of work.
• When a database access thread is pooled, it waits for the next request from a client to start a new unit of work.

Thread and Enclave Relationship

• For every database access thread, an independent enclave is created.
• The way DDF uses enclaves relates directly to whether the DDF thread can become inactive.
• Active mode threads are treated as a single enclave from the time they are created until the time they are terminated.
• Inactive mode threads are treated as an enclave when they are active. When the thread is pooled, such as during think time, it is not using an enclave.

Common Practices for the WLM rules in a DDF setting

• Use the subsystem of the remote request as the first part of the rule in doing classification.
• Use the other available filters for the subsequent levels of classifications
• Divide the known workloads into groups based on the types of query (static or dynamic)
• For transactions using dynamic queries, assign a service class with a resource group specifying a MAX threshold in order to limit the CPU consumption

Stored Procedures and the WLM

• DB2 stored procedures use WLM to manage the performance of individual client requests.
• The WLM can assign dispatching priorities to stored procedure transactions based on the service class goals.
• Requests are handled in priority order.
• Stored procedures inherit the z/OS dispatching priority of the DB2 thread that issues the CALL statement.
• User-defined functions inherit the priority of the DB2 thread that invoked the procedure.

More Stored Procedures and the WLM

• The preferred way to run these stored procedures is in multiple WLM-established address spaces (rather a single DB2-established address space).
• Multiple DB2 address spaces for stored procedures with multiple tasks at each address space allow clients to run more concurrent transactions compared to a single address space.
• The multiple address spaces also provide improved program isolation for stored procedures.
• Each address space is associated with a WLM application environment that you specify.
• An application environment is an attribute that you associate on the CREATE statement for the function or procedure.
• The environment determines which JCL procedure is used to run a particular stored procedure.