DB2 requests originate from diverse sources, including batch, cics, Distributed Data facilities (DDf), and saP. related DB2 cPu usage can be recorded in resource measurement facility (rmf), DB2, system management facility (smf) 30, and other subsystem records. Proper selection and interpretation of these values will vary with transaction source, DB2 environment, product levels, and analysis objectives. analysts must be careful to include all desired values and avoid counting the same logical utilization multiple times.
This article discusses the sources and analyses of DB2 cPu metrics and corresponding response times. examples will include cics, DDf, and saP. the goal of this article is to provide an overview of DB2 cPu and response metrics for traditional large system performance and capacity analysts in an mvs environment (esa, os/390, z/os, etc.). included at the end are sources of DB2 record layouts and references. other good definition sources are the glossaries in the DB2 Installation Guide starting with DB2 v8 and DB2 Administration Guide for earlier releases, and your DB2 specialists. Data sources discussed will be primarily from SMF. Specific fields will be referenced, but it’s always best to validate field names for the DB2 levels installed. Examples shown use real data, but they don’t necessarily all represent running systems. Obviously, good performance is subjective and varies with objectives.
Most installations have a central performance analysis and capacity planning function (group, person, or part of a person) that reports, tracks, and evaluates overall performance and capacity requirements. Skills that exist in the central function are typically traditional mainframe- and operating system-related. Detailed installation and analysis skills tend to exist in separate functional areas for subsystems such as DB2, IMS, and CICS. Reporting typically includes:
- Installation totals
- Systems (e.g., MVS image)
- Subsystems such as Time Sharing Option (TSO), CICS, and DB2
- Workloads (e.g., accounting, development).
The central function should have enough knowledge of installed subsystems to provide system-level analysis and reporting. It’s also necessary to know when to get appropriate subsystem specialists involved. Teamwork and communication are key factors.
From a high level, not much has changed for many years. MVS and DB2 have been around a long time. CPU cycles are the most important planning resource. Paging is to be minimized (though it’s rarely a current issue), and balanced I/O capabilities must be available. At a detail level, change is continuous. MVS and DB2 provide a highly flexible, evolving architecture, which can cause significant performance data deviations across installations as a result of different levels, setups, applications, development techniques, and hardware. As the evolving architecture is exploited, it’s necessary to keep reporting systems up-to-date. Examples of this evolution include enclaves, preemptible System Request Blocks (SRBs), and System z Integrated Information Processor (zIIP).
Before getting to data, it’s important to understand the basic structure of DB2 and how requestors of service interface with it. In simple terms, DB2 can be thought of as being a super access method. It uses MVS Subsystem Interface (SSI) protocols and crossmemory services. Data sharing among multiple DB2s on different images is accomplished using the coupling facility. There can be multiple DB2 subsystems in an MVS image, but most production work will typically be performed by only one subsystem. While there’s generally no performance advantage to having multiple DB2 subsystems on an image, there’s value to separate development and test DB2 subsystems.
A DB2 subsystem (identified by SSID) includes at least three system address spaces (see Figure 1). A Master or System Services Address Space (MSTR or SSAS) provides overall control functions. The database manager (DBM1 or DBAS) contains buffer pools, an Environment Descriptor Management (EDM) pool, and supporting code. The EDM pool contains information on currently open databases and transaction (plan) descriptions. The Inter-Regional Resource Lock Manager (IRLM) provides locking support.