DB2 PM Usage Guide Update

SG24-2584-00
International Technical Support Organization
DB2 PM Usage Guide Update
October 1995
IBML
SG24-2584-00
October 1995
Take Note!
Before using this information and the product it supports, be sure to read the general information under
“Special Notices” on page xv.
First Edition (October 1995)
This edition applies to Version 4 of IBM DATABASE 2 Performance Monitor, Program Number 5665-102 for use
with the MVS Operating System.
Order publications through your IBM representative or the IBM branch office serving your locality. Publications
are not stocked at the address given below.
An ITSO Technical Bulletin Evaluation Form for reader′s feedback appears facing Chapter 1. If the form has been
removed, comments may be addressed to:
IBM Corporation, International Technical Support Organization

Dept. 471 Building 070B
5600 Cottle Road
San Jose, California 95193-0001
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
 Copyright International Business Machines Corporation 1995. All rights reserved.

Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Abstract
This document is unique in its detailed coverage of a monitoring strategy for the
DB2 for MVS/ESA environment. It focuses on the facilities offered by IBM
DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4. It provides
information about Online Monitor and Batch functions for performance
monitoring in the IBM DATABASE 2 for MVS/ESA Version 4 environment.
This document is written for system programmers, database administrators, and

any one who has a need to monitor performance in the DB2 for MVS/ESA
environment. Some knowledge of DB2 PM Version 4 is assumed.
(196 pages)
 Copyright IBM Corp. 1995 iii

iv DB2 PM
Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
How This Document Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
International Technical Support Organization Publications . . . . . . . . . . xviii
ITSO Redbooks on the World Wide Web (WWW) . . . . . . . . . . . . . . . . . xix
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Chapter 1. Performance Management . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Managing DB2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Establishing Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Service Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4 Initial Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.5 Internal Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.6 Coding and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.7 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Developing a Monitoring Policy . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Monitoring Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Monitoring Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Rate of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 Active Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.6 Reporting Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.7 Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.8 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.9 Monitoring Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 2. DB2 PM Monitoring Facilities . . . . . . . . . . . . . . . . . . . . . . 15

2.1 DB2 PM Online Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Exception Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 HISTORY Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 DIAGNOSE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Collect Report Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 DB2 PM Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.7.1 Report Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7.2 Traces and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7.3 Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.4 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8 Interactive Report Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9 Who Can Use DB2 PM Facilities? . . . . . . . . . . . . . . . . . . . . . . . . 27
Chapter 3. Using DB2 PM for Exception Processing . . . . . . . . . . . . . . . 31

3.1 Exception Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1 Exception Event Processing . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2 Periodic Exception Processing . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Display Exception Processing . . . . . . . . . . . . . . . . . . . . . . . . 37
 Copyright IBM Corp. 1995 v

3.2 Activating the Exception Processor . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Exception Display Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.1 Periodic Exception Conditions . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Display Exception Conditions . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Alternative Reporting Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.1 Exception Log File Data Set . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.2 DPMOUT Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.3 FILE Subcommand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Deactivating Exception Processing . . . . . . . . . . . . . . . . . . . . . . . 44
3.6 Setting Exception Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.1 Defining a Threshold Data Set . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.2 Defining Threshold Data Set Entries . . . . . . . . . . . . . . . . . . . . 45
3.6.3 Fields for Populating the Threshold Data Set . . . . . . . . . . . . . . . 45
3.7 Exception Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.7.1 How Profiling Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.7.2 Input Data Used for Profiling . . . . . . . . . . . . . . . . . . . . . . . . 49
3.8 Data Collector and History Function . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.1 Collecting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.8.2 Amount of Data to Collect . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.8.3 Collection Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.8.4 Using the History Function . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.9 Problem Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.9.1 The Diagnose Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.9.2 Invoking Diagnose Function . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.10 Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.10.1 Batch Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.10.2 DB2 PM Online Monitor Explain . . . . . . . . . . . . . . . . . . . . . . 59
3.10.3 Source Explain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.10.4 Explain Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.11 Problem Resolution Using DB2 PM Online Monitor Exceptions . . . . . . 61
3.11.1 Exception Reported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.11.2 View Periodic Exception Log . . . . . . . . . . . . . . . . . . . . . . . . 63
3.11.3 Subsystem or Application Problem . . . . . . . . . . . . . . . . . . . . 63
3.11.4 Data Collector Active? . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.11.5 Thread and Statistics History Data . . . . . . . . . . . . . . . . . . . . 63
3.11.6 Diagnose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.11.7 Detailed Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.11.8 Problem Occurring or Recreatable: DIAGNOSE . . . . . . . . . . . . 64
3.11.9 Configure Collect Task . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.11.10 Accounting and Statistics Reports . . . . . . . . . . . . . . . . . . . . 64
3.11.11 Switch SMF or Process Active SMF . . . . . . . . . . . . . . . . . . . 65
3.11.12 Set Up Exception Triggers . . . . . . . . . . . . . . . . . . . . . . . . 65
Chapter 4. Using DB2 PM for Periodic Monitoring . . . . . . . . . . . . . . . . 67

4.1 Monitoring Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2 Report Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 Collecting DB2 Performance Data . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.1 SMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.2 GTF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.3 DPMOUT Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.4 DB2 PM Collect Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4 Exception Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5 Tailored Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.6 Accounting TOP Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.6.1 Accounting TOP ONLY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
vi DB2 PM
4.6.2 Accounting TOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.7 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.7.1 Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.7.2 Accounting by Field Identifier Graph . . . . . . . . . . . . . . . . . . . . 80
4.7.3 Accounting by DB2 PM Identifier Graph . . . . . . . . . . . . . . . . . . 81
4.7.4 Statistics System Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.7.5 Frequency Distribution Graph . . . . . . . . . . . . . . . . . . . . . . . . 83
4.8 MAINPACK and PACKAGE Identifiers . . . . . . . . . . . . . . . . . . . . . . 85
4.9 Correlation Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.10 Time Zone Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.11 Solving Periodic Exceptions Using DB2 PM . . . . . . . . . . . . . . . . . 86
Chapter 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.1 Sort Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.2 Constrained Buffer Pool Problem . . . . . . . . . . . . . . . . . . . . . . . 117
5.3 Class 1 Elapsed Time Problem . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.4 Access Path Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.5 Locking Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Chapter 6. Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Chapter 7. Support for Distributed and Data Sharing Environments . . . . . 179

7.1 Distributed Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
7.1.1 DB2 PM Online Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . 179
7.1.2 DB2 PM Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.2 Data Sharing Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.2.1 DB2 PM Online Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . 181
7.2.2 DB2 PM Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Appendix A. DB2 Trace Data As Input to DB2 PM Report Set . . . . . . . . . 183
Appendix B. DB2 PM Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Appendix C. Significant Exception Reporting Fields . . . . . . . . . . . . . . 187
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Contents vii
viii DB2 PM
Figures
1. Explain SQL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Road Map of Problems Found in Periodic Exception Monitoring . . . . . 12
3. Road Map of Problems Found in EVENT Exception Monitoring . . . . . . 12
4. Road Map of Problems Found in Exception Reports . . . . . . . . . . . . 13
5. IBM Database 2 Performance Monitor Panel . . . . . . . . . . . . . . . . 16
6. DB2 PM Online Monitor Main Menu . . . . . . . . . . . . . . . . . . . . . . 17
7. Exception Processor Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Source Explain Options Panel . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Diagnosis of Thread Window . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Exception Event Summary Panel . . . . . . . . . . . . . . . . . . . . . . . . 33
11. Exception Event Summary Panel: Deadlock Data . . . . . . . . . . . . . . 34
12. Periodic Exception Processor Panel . . . . . . . . . . . . . . . . . . . . . . 35
13. Periodic Exception Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14. Periodic Exception Notification Window . . . . . . . . . . . . . . . . . . . . 39
15. Look Selections Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
16. Periodic Exceptions List Window . . . . . . . . . . . . . . . . . . . . . . . . 41
17. Thread Summary Panel Showing Exceptions . . . . . . . . . . . . . . . . 42
18. Exception Profiling Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
19. Exception Profiling Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
20. Exception Threshold Field Details Panel . . . . . . . . . . . . . . . . . . . 52
21. Sample Diagnosis Rules of Thumb Panel . . . . . . . . . . . . . . . . . . . 55
22. Diagnosis of Thread Window: Diagnose Function . . . . . . . . . . . . . . 56
23. Constraint Information Panel . . . . . . . . . . . . . . . . . . . . . . . . . . 57
24. Road Map for Problem Resolution: DB2 PM Online Monitor Exceptions 62
25. Accounting Short Exception Report . . . . . . . . . . . . . . . . . . . . . . 72
26. JCL for User-Tailored Reporting Feature . . . . . . . . . . . . . . . . . . . 73
27. User-Tailored Accounting Report . . . . . . . . . . . . . . . . . . . . . . . 74
28. Accounting TOP ONLY Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 74
29. Accounting TOP ONLY Report . . . . . . . . . . . . . . . . . . . . . . . . . 75
30. Accounting TOP Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
31. Accounting TOP List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
32. Graphics Selection Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
33. Interactive Report Selections Panel . . . . . . . . . . . . . . . . . . . . . . 78
34. JCL for Accounting and Statistics Reduce, Report, and Save . . . . . . . 78
35. JCL for Accounting and Statistics Reduce, Restore, Report, and Save . 80
36. Accounting by Field Identifier Graph . . . . . . . . . . . . . . . . . . . . . 81
37. Accounting by DB2 PM Identifier Graph: TCB . . . . . . . . . . . . . . . . 82
38. Accounting by DB2 PM Identifier Graph: SQL . . . . . . . . . . . . . . . . 82
39. Statistics System Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
40. Accounting by Field Identifier Graph for Comparison with Freq Dist
Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
41. Frequency Distribution Graph . . . . . . . . . . . . . . . . . . . . . . . . . . 85
42. Road Map for Problem Resolution: Periodic Exceptions . . . . . . . . . . 87
43. Data Available to DB2 PM for Problem Determination . . . . . . . . . . . 88
44. Accounting Reduce and Report with Include and Order . . . . . . . . . . 90
45. Statistics Reduce and Report . . . . . . . . . . . . . . . . . . . . . . . . . . 91
46. High Class 1 and Low Class 2 Elapsed Times . . . . . . . . . . . . . . . . 92
47. High Class 2 Elapsed and TCB Times . . . . . . . . . . . . . . . . . . . . . 93
48. Explain Plan Report Extract . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
49. SQL Activity Trace Summarized by Cursor . . . . . . . . . . . . . . . . . . 94
50. High NOT ACCOUNTED Time . . . . . . . . . . . . . . . . . . . . . . . . . . 95
 Copyright IBM Corp. 1995 ix

51. High Class 3 Lock/Latch Time . . . . . . . . . . . . . . . . . . . . . . . . . 96
52. Lock Suspension Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
53. Lockout Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
54. Statistics Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
55. Accounting TOP Report List: Sort Problem . . . . . . . . . . . . . . . . . 104
56. Exception Threshold Category Selection Panel: Sort Problem . . . . . 105
57. Exception Threshold Field Selection Panel: Sort Problem . . . . . . . . 106
58. Exception Threshold Field Details Panel: Sort Problem . . . . . . . . . 107
59. Exception Processor Panel: Sort Problem . . . . . . . . . . . . . . . . . 108
60. Look Selections Menu: Sort Problem . . . . . . . . . . . . . . . . . . . . 109
61. Periodic Exceptions List Window: Sort Problem . . . . . . . . . . . . . . 109
62. Collect Report Data Panel: Sort Problem . . . . . . . . . . . . . . . . . . 110
63. Trace Configuration Window: Sort Problem . . . . . . . . . . . . . . . . 110
64. Trigger Immediately Window: Sort Problem . . . . . . . . . . . . . . . . 111
65. Accounting Long Report Extract: Sort Problem . . . . . . . . . . . . . . 112
66. Statistics Long Report Extract: Sort Problem . . . . . . . . . . . . . . . . 113
67. Storage Sizes and Connections Panel: Sort Problem . . . . . . . . . . . 114
68. Accounting Long Report Extract: Increased Sort Pool Size . . . . . . . 115
69. Statistics Long Report Extract: Increased Sort Pool Size . . . . . . . . 116
70. Accounting TOP Report List: Constrained Buffer Pool Problem . . . . 118
71. Accounting Short Report Extract: Constrained Buffer Pool Problem . . 119
72. Accounting Long Report Extract: Constrained Buffer Pool Problem . . 120
73. Statistics Long Report Extract: Constrained Buffer Pool Problem . . . 121
74. Diagnosis of Thread Window: Constrained Buffer Pool Problem . . . . 122
75. Accounting Long Report Extract: Increased Buffer Pool BP1 Size . . . 123
76. Statistics Long Report Extract: Increased Buffer Pool BP1 Size . . . . 124
77. Exception Threshold Category Selection Panel: Class 1 Elapsed Time
Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
78. Exception Threshold Field Selection Panel: Class 1 Elapsed Time
Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
79. Exception Threshold Field Details Panel: Class 1 Elapsed Time
Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
80. Exception Processor Panel: Class 1 Elapsed Time Problem . . . . . . . 128
81. Exception Notification Window: Class 1 Elapsed Time Problem . . . . . 129
82. Look Selections Menu: Class 1 Elapsed Time Problem . . . . . . . . . 130
83. Periodic Exceptions List Window: Class 1 Elapsed Time Problem . . . 131
84. Thread Detail Panel Invoking Diagnose: Class 1 Elapsed Time Problem 132
85. Diagnosis of Thread Window: Class 1 Elapsed Time Problem . . . . . 133
86. Active Processing Window: Class 1 Elapsed Time Problem . . . . . . . 133
87. Thread Detail Panel (SQL Statement and Package): Class 1 Elapsed
Time Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
88. SQL Statement and Package Window: Class 1 Elapsed Time Problem 135
89. DB2 Explain Output Panel: Class 1 Elapsed Time Problem . . . . . . . 136
90. DB2 Explain Output (Table Information): Class 1 Elapsed Time Problem 137
91. Table Information Window: Class 1 Elapsed Time Problem . . . . . . . 137
92. Index Information Window: Class 1 Elapsed Time Problem . . . . . . . 138
93. Key Column Information Window: Class 1 Elapsed Time Problem . . . 138
94. DB2 Explain Output (Host Variables): Class 1 Elapsed Time Problem . 139
95. Host Variable Definition Window: Class 1 Elapsed Time Problem . . . 140
96. Accounting Exception Report: Access Path Problem . . . . . . . . . . . 142
97. Accounting Long Report Extract: Access Path Problem . . . . . . . . . 143
98. DB2 Explain Output Panel: Access Path Problem . . . . . . . . . . . . . 144
99. Table Information Window: Access Path Problem . . . . . . . . . . . . . 144
100. Index Information Window: Access Path Problem . . . . . . . . . . . . . 145
101. Key Column Selection Window: Access Path Problem . . . . . . . . . . 146
x DB2 PM
102. DB2 Explain Output (Corrected SQL Statement): Access Path Problem 147
103. Accounting Long Report Extract: With Expected Access Path . . . . . . 148
104. Exception Processor Panel: Locking Problem . . . . . . . . . . . . . . . 149
105. Exception Notification Window: Locking Problem . . . . . . . . . . . . . 150
106. Look Selections Menu: Locking Problem . . . . . . . . . . . . . . . . . . 150
107. Exception Event Summary Panel: Locking Problem . . . . . . . . . . . . 151
108. Exception Event Detail Panel: Locking Problem . . . . . . . . . . . . . . 152
109. Trace Configuration Window: Locking Problem . . . . . . . . . . . . . . 153
110. IFCID Selection Window: Locking Problem . . . . . . . . . . . . . . . . . 154
111. Trigger Immediately Window: Locking Problem . . . . . . . . . . . . . . 155
112. Lockout Trace: Locking Problem . . . . . . . . . . . . . . . . . . . . . . . 156
113. SQL Trace Summarized by Occurrence: Locking Problem . . . . . . . 158
114. Explain Menu: Locking Problem . . . . . . . . . . . . . . . . . . . . . . . 159
115. SQL Statement List Panel (DBRM REVP22): Locking Problem . . . . . 159
116. SQL Statement List Panel (DBRM REVP11): Locking Problem . . . . . 160
Figures xi
xii DB2 PM
Tables
1. Monitor Trace Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2. Exception Reporting Fields for the System Programmer . . . . . . . . . . 46
3. Exception Reporting Fields for the Database Administrator . . . . . . . . 48
4. The 12-Byte Correlation ID Field and the Default Translation . . . . . . . 86
5. Accounting Field 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
34. Statistics Field 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
43. Statistics Field 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
 Copyright IBM Corp. 1995 xiii

65. DB2 PM Report Set and DB2 Trace Data . . . . . . . . . . . . . . . . . . 183
66. DB2 PM VSAM Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
67. DB2 PM Non-VSAM Data Sets . . . . . . . . . . . . . . . . . . . . . . . . 186
68. Significant Exception Reporting Fields . . . . . . . . . . . . . . . . . . . 187
xiv DB2 PM
Special Notices
This publication is intended to help system programmers, database

administrators, and in general any one who has a need to monitor performance
in the DB2 for MVS/ESA environment. The information in this publication is not
intended as the specification of any programming interfaces that are provided by
IBM DATABASE 2 for MVS/ESA Version 4 and IBM DATABASE 2 Performance
Monitor for MVS (DB2 PM) Version 4. See the PUBLICATIONS section of the IBM
Programming Announcement for DB2 and DB2 PM products for more information
about what publications are considered to be product documentation.
References in this publication to IBM products, programs or services do not

imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program, or service is not intended
to state or imply that only IBM′s product, program, or service may be used. Any
functionally equivalent program that does not infringe any of IBM′s intellectual
property rights may be used instead of the IBM product, program or service.
Information in this book was developed in conjunction with use of the equipment
specified, and is limited in application to those specific hardware and software
products and levels.
IBM may have patents or pending patent applications covering subject matter 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 the IBM Director of
Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594 USA.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The use of this information or the
implementation of any of these techniques is a customer responsibility and
depends on the customer′s ability to evaluate and integrate them into the
customer′s operational environment. While each item may have been reviewed
by IBM for accuracy in a specific situation, there is no guarantee that the same
or similar results will be obtained elsewhere. Customers attempting to adapt
these techniques to their own environments do so at their own risk.
The following terms are trademarks of the International Business Machines

Corporation in the United States and/or other countries:
CICS DATABASE 2
DB2 DFSMS
DFSMS/MVS DFSMSdss
DFSORT DRDA
IBM MVS/ESA
OS/2 RACF
RMF S/390
Sysplex Timer System/390
VTAM 3090
The following terms are trademarks of other companies:
C-bus is a trademark of Corollary, Inc.
PC Direct is a trademark of Ziff Communications Company and is

used by IBM Corporation under license.
 Copyright IBM Corp. 1995 xv

UNIX is a registered trademark in the United States and other
countries licensed exclusively through X/Open Company Limited.
Windows is a trademark of Microsoft Corporation.
Other trademarks are trademarks of their respective companies.
xvi DB2 PM
Preface
This document provides information about how to monitor performance in the

DB2 for MVS/ESA environment with the Online Monitor and Batch functions of
DB2 PM for MVS.
This document is intended for system programmers, database administrators,

and any one who has a need to monitor performance in the DB2 for MVS/ESA
environment.
How This Document Is Organized

The document is organized as follows:
• Chapter 1, “Performance Management”
This chapter describes the elements comprising performance management,
from the first principles related to planning and developing a performance
strategy, through to the ongoing business as usual approach of performance
management.
• Chapter 2, “DB2 PM Monitoring Facilities”
This chapter describes the facilities that DB2 PM offers to monitor your DB2
subsystem by providing information about both current and past activity to
determine specific performance problems in DB2. This chapter also
identifies who can use these facilities.
• Chapter 3, “Using DB2 PM for Exception Processing”
This chapter discusses at length how to use DB2 PM for exception
monitoring.
• Chapter 4, “Using DB2 PM for Periodic Monitoring”
This chapter describes periodic monitoring and explains how it can help you
maintain good DB2 subsystem performance.
• Chapter 5, “Scenarios”
This chapter shows, through different scenarios, a structured approach to
problem solving with DB2 PM.
• Chapter 6, “Checklists”
This chapter documents most of the important fields in Accounting and
Statistics useful for problem determination. .
• Chapter 7, “Support for Distributed and Data Sharing Environments”
This chapter describes briefly the facilities that DB2 PM provides to monitor
the DB2 activities in distributed and data sharing environments. .
• Appendix A, “DB2 Trace Data As Input to DB2 PM Report Set”
This appendix documents the DB2 traces that should be activated for the
specific DB2 PM report sets.
• Appendix B, “DB2 PM Data Sets”
This appendix documents the attributes that you should use in DB2 PM
Version 4 for the most useful VSAM and non-VSAM data sets.
 Copyright IBM Corp. 1995 xvii

• Appendix C, “Significant Exception Reporting Fields”
This appendix documents the significant accounting and statistics exception
reporting fields.
Related Publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this document.
• IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4 General
Information Manual , GH12-6171
• IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4 Online
Monitor User ′ s Guide , SH12-6165
• IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4 Batch
User ′ s Guide , SH12-6164
• IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4 Report
Reference, Volume 1 , SH12-6163
• IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4 Report
Reference, Volume 2 , SH12-6166
• IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4
Command Reference , SH12-6167
• IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4
Messages , SH12-6168
• IBM DATABASE 2 for MVS/ESA Version 4 Administration Guide , SC26-3265
• Graphic Data Display Manager/Presentation Graphics Feature: Interactive
Chart Facility User ′ s Guide , SC33-0328
International Technical Support Organization Publications

• DB2 V4 Data Sharing Performance Topics , SG24-4611
• DB2 V4 Non-Data-Sharing Performance Topics , SG24-4562
• DB2 V3 Performance Topics , GG24-4284
• DB2 Packages: Implementation and Use , GG24-4001
A complete list of International Technical Support Organization publications, with

a brief description of each, may be found in:
To get a catalog of ITSO technical publications (known as “redbooks”), VNET

users may type:
TOOLS SENDTO WTSCPOK TOOLS REDBOOKS GET REDBOOKS CATALOG
A listing of all redbooks, sorted by category, may also be found on MKTTOOLS

as ITSOPUB LISTALLX. This package is updated monthly.
xviii DB2 PM
How to Order ITSO Redbooks
IBM employees in the USA may order ITSO books and CD-ROMs using
PUBORDER. Customers in the USA may order by calling 1-800-879-2755 or by
faxing 1-800-284-4721. Visa and Master Cards are accepted. Outside the
USA, customers should contact their local IBM office.
Customers may order hardcopy ITSO books individually or in customized

sets, called GBOFs, which relate to specific functions of interest. IBM
employees and customers may also order ITSO books in online format on
CD-ROM collections, which contain redbooks on a variety of products.
ITSO Redbooks on the World Wide Web (WWW)

Internet users may find information about redbooks on the ITSO World Wide Web
home page. To access the ITSO Web pages, point your Web browser to the
following URL:
http://www.redbooks.ibm.com/redbooks
IBM employees may access LIST3820s of redbooks as well. Point your web
browser to the IBM Redbooks home page:
http://w3.itsc.pok.ibm.com/redbooks/redbooks.html
Acknowledgments
This project was designed and managed by:
Ravi Kumar
International Technical Support Organization, San Jose Center
The authors of this document are:
Maria Sueli de Almeida

IBM Brazil
Mike Groom
IBM UK
This publication is the result of a residency conducted at the International

Technical Support Organization, San Jose Center.
Thanks to Akira Shibamiya of IBM Development, Santa Teresa, the consultant on

this project, for his guidance, encouragement, and support.
Thanks to the following people for the invaluable advice and guidance they
provided in the production of this document:
Wolfgang Barth
GSDL, IBM Germany
Franz-Peter Boley
GSDL, IBM Germany
Preface xix
John Campbell
IBM Development, Santa Teresa
Roy Cornford
IBM United Kingdom
Harold Hall
IBM Development, Santa Teresa
Stan Hoey
IBM United Kingdom
Namik Hrle
Aspect Computing, Australia
Greg Hunt
Aspect Computing, Australia
Peter Salz
ISSC, Australia
Thanks to the following people for the invaluable help they provided in setting up
and administering the computing facilities:
Stefan Benk
GSDL, IBM Germany
Prakash Tendulkar
Information Systems, Santa Teresa
Thanks to Maggie Cutler for editing this book and to Stephanie Manning for
editorial assistance.
xx DB2 PM
Chapter 1. Performance Management
This chapter describes the elements comprising performance management, from

the first principles related to planning and developing a performance strategy,
through to the ongoing business as usual approach of performance management.
The business enterprise of the 1990s relies on the support of data processing for
its daily information requirements. Data processing environments are often
complex, involving multiple systems and large amounts of data accessed both
locally and remotely, and usually supported by a managed network.
The delivery of information from business-critical applications is dependent on a

diversity of skilled professionals responsible for collectively developing and
implementing a performance management strategy for a customer.
Although many different professionals are involved in the process of delivering

the customer solution, some have more direct involvement in the ongoing
process than others. You should understand that all elements, from capacity
planning and network design through to application development, play a major
part in the overall performance of the system.
The responsibility may encompass these job families:

• Capacity planner
• Database administrator
• Application developer
• Operations personnel
• Systems programmer
• Network specialist
• Performance specialist.
1.1 Managing DB2 Performance

Achieving and maintaining good DB2 performance is vital to everyone who has
any dealings with the DB2 database environment. The management of
performance is a process that begins with application design and involves:
• Establishing performance objectives
• Planning performance monitoring
• Executing the performance plan
• Analyzing reports to determine whether performance objectives have been
achieved.
If objectives are achieved, monitoring can be relaxed and conducted on a

periodic basis to ensure that targets remain within scope.
If the performance objectives are not met you should:

• Identify the major factors that prevent the realization of objectives.
• Identify areas where compromises can be made.
 Copyright IBM Corp. 1995 1

• Tune the system by adjusting characteristics to improve performance.
The performance management process is ongoing. Extra unrelated workload,

changes in objectives, and additional constraints will challenge the original
specification and may result in degraded performance. Thus monitoring and
rechecking the results against agreed objectives is a regular task.
1.1.1 Establishing Objectives

The way in which the term good performance relates to your DB2 subsystem is
entirely dependent on the data processing needs of your site. It may be
perfectly acceptable for a transaction to take 3 seconds to complete in one
environment, however, in a different environment where thousands of
transactions are performed per hour, a transaction processing time of 3 seconds
clearly would be unacceptable.
Your performance objectives should be realistic, achievable within budget

constraints, and most importantly measurable.
Common objectives you should consider are:

• Acceptable response times
• Average throughput by transaction for a given time frame
• System availability, including scheduled maintenance windows for hardware
and software. An example would be the sometimes unrealistic expectation
of 24x7 system availability.
For your application, estimate the resource requirements for each transaction
type and translate those into measurable objectives.
Using IBM′s DB2 Estimator for Windows (hereafter referred to as Estimator), you
can estimate the CPU and I/O resource requirements for SQL. These estimates
are especially useful, if you do not have much experience with SQL or need to
understand whether the application will be able to perform adequately after it is
developed. Using Estimator you can also estimate the minimum response time
that might be expected, but you must realize that contention from many sources
can elongate actual response times. Estimator in general is capable of
estimating the performance of SQL in reasonably tuned environments. If your
actual performance is much worse, it is possible that you have a tuning problem
and need to use DB2 performance monitor (DB2 PM) to identify and correct it.
2 DB2 PM
The following factors will provide you with some guidance for forming realistic
objectives:
• Network response
Whereas response from the processor is likely to be measured in fractions of
a second, responses in networks are measured in seconds. A poorly
performing or overloaded network will always be a significant aspect of
response time no matter how fast the processor. Distributed system queries
slow response further.
• DASD response
I/O operations are responsible for the major portion of internal processing
time for a transaction. Consider actions to reduce the I/O access per
transaction to a minimum.
• Response times
Response times are difficult to predict before design has been completed.
Therefore plan to review response time frequently. Be aware that distributed
processing adds an overhead at both the local and remote sites.
• Workload
Aim to base the estimates on peak workloads, paying special attention to
daily, weekly, and month end peaks. You should also consider downtime for
maintenance as peaks will exist following such activity.
1.1.2 Service Levels

You, but more commonly the business process, dictate the requirement for
performance, and a mutual agreement on acceptable performance will be
formalized into a Service Level Agreement. These agreements often include:
• Expectations of query response time
• Transaction throughput
• Batch throughput
• Housekeeping schedules.
1.1.3 Workload
It is important for you to recognize the different types of workload that exist
within a system. You should examine the workload and group transactions by
their function. Some transactions perform the same type of function (for
example, order entry) and have a common identifiable workload profile. Other
transactions, for example, QMF queries within a management information
system (MIS) environment or SPUFI queries, may be diverse by their nature and
difficult to group.
1.1.4 Initial Planning

Plan to gather the resource requirements by estimating the following:
Transactions
• Maximum rate of transaction per minute,
per hour, per day
• Number of I/O operations per transaction
• Average and maximum processor usage per transaction
Chapter 1. Performance Management 3

• Size of tables
• Table space definition
• Index key distribution
• Support personnel.
Estimator can help in estimating the processor usage per transaction.
Query times
• Online query processing load
• Canned or user-written queries
• Size of tables
• Table space definition
• Index key distribution
• Support personnel.
Estimator can help in estimating the CPU and I/O resources required for
queries.
Batch processing
• Length of batch window
• Batch processing load
• Size of tables
• Housekeeping routines.
Estimator can help in estimating the CPU and I/O resources required for
batch jobs.
1.1.5 Internal Design

At this stage the application design is transposed from a high-level business
goal into a more recognizable application specification. It is very likely that
many of the original estimates will need to be revised following this more
detailed look at the structure of the application.
1.1.6 Coding and Testing

Formal specifications for the performance of the entire system, down to single
SQL calls, are available. Application developers use these specifications to
ensure that their programs meet the objectives. This is a crucial stage as poor
design or coding can have a lasting effect on your application. It is often
impossible for you to alter the application once in production, and you should
seize every opportunity to get it right at this stage.
Reorganize data after analyzing the report from the execution of the RUNSTATS
utility. Data organization would then reflect the ideal conditions facilitating the
physical database design certification. You can then consider these practical
suggestions (see Figure 1 on page 5) for writing applications that perform within
design specifications:
• Write SQL with the specified access path in mind
• Plan to check the access path by using the DB2 PM function Explain while
developing the application.
4 DB2 PM
DB2 PM allows the developer writing applications to Explain the source
statements, either singly or in blocks of code, while developing the code.
• Amend the statement to conform to the specification if there is a deviation
from the expected access path shown by Explain .
• Repeat this process at the unit test and system test stages.
When the application goes into production, there must be no surprises.
---------------
| Code SQL |
| Statement |
---------------
|
|
--------------- ---------------
| Explain |<----------| Recode SQL |
| SQL | | Statement |
| Statement | ---------------
--------------- |
| |
| |
--------------- |
| Access Path | N |
| Meets Design|__________________|
| Objectives? |
---------------
|Y
|
----------
|Continue|
----------
Figure 1. Explain SQL Statements
You should understand the hardware configuration of the application

development environment and the planned production environment. Differences
in CPU type, storage capacity and its configuration, processor speed, special
hardware features such as sort assist, and processor load will cause inaccurate
results. By all means, do not base your predictions for transaction performance
on a development environment where the hardware outperforms the hardware
used in the production environment.

1.1.7 Review
Run a postdevelopment review to check the application. This review should
examine every aspect of the application in detail, and you should use the results
to confirm the health of the application or identify specific areas where tuning
may be necessary. The following steps will help in identifying the actions
required:
1. Measure system performance and response times
Measure your key transactions, that is, those that are critical to the
business. In particular measure responses from key update and query only
transactions.
Ensure that the batch cycle completes comfortably within the batch
window. Plan for restarting jobs that may fail. For DB2 jobs ensure that
there are frequent commit points within the batch jobs. Otherwise jobs
may experience very long backout times, depending on where the failure
occurs and how much work has been performed.
2. Make housekeeping, including backup and recovery, an integral part of
application design. Ensure that resources are available for the
housekeeping functions.
3. Identify the resources that are under pressure, so that you can monitor them
more regularly than others.
4. Document any aspect of the application or system that fails to meet its
objectives. Set time scales and ensure that actions are assigned to
individuals or groups for problem resolution.
5. Project processor use against planned future system growth to ensure that
adequate capacity will be available.
1.2 Developing a Monitoring Policy

Gear your monitoring policy toward identifying unusual and unexpected
problems or trends that will, if not remedied, lead to problem situations.
Remember that applications that do not perform to specifications in the
development environment will not perform to specifications in an active
production environment. The key to effective performance monitoring is
therefore to identify your out-of-line situations and thereby reduce the amount of
information that needs to be examined.
The monitoring process must be simple and easy to understand—to this end, the
many new functions of DB2 PM can offer significant benefit. Present only that
information that has exceeded the boundaries set by the installation personnel
or alternatively alert personnel when a problem has occurred. The aim of your
policy should be to promote proactive monitoring, that is, to identify potential
problems or trends before they become critical. This approach will give you
time to formulate a calm, rational response to the situation and minimize the
impact on your services.
6 DB2 PM
1.2.1 Monitoring Scope
The performance of your DB2 transaction or query depends not only on the
performance of the DB2 subsystem, but also on the transaction manager such as
CICS or IMS, and the system itself. Therefore you must tune the environment in
which the DB2 subsystem is operating before you tune DB2. You need to
address the root cause of the problem. For example, if the MVS system is
overloaded, tuning a DB2 subsystem is unlikely to improve the MVS system
performance. DB2 subsystem performance can be improved only by improving
or balancing the load on the MVS system.
These specialized tools are available to help you monitor the different system
components:
• EDM for CICS
• IMS DC monitor for IMS
• RMF for MVS
• NetView for VTAM.
The relationship between the different system and performance tools is complex,
and not within the scope of this book. Refer to the IBM DATABASE 2 for
MVS/ESA Version 4 Administration Guide for more information.
1.2.2 Monitoring Frequency

Frequency applies only to periodic monitoring, as exception monitoring is a
function that is enabled and is then continuously active. Exceptions are reported
as they occur.
The frequency of periodic monitoring can be determined by a number of factors,

which include the maturity of the system and the rate of change. If your system
is new, consider producing reports frequently; daily would be a starting point.
Review key fields against objectives. As the system becomes more stable, in
terms of workload fluctuations and peaks, you can relax the periodic monitoring
interval. For mature systems consider producing reports on a weekly basis. The
types of reports and key fields are discussed in Chapter 3, “Using DB2 PM for
Exception Processing” on page 31.
1.2.3 Rate of Change

Consider increasing specific periodic monitoring when significant changes are
being made, either to the system elements, that is, processor, I/O subsystem,
storage or to the application mix; for example, a new application release,
additional workload, changing business need, or increased volumes of data.
Always be flexible and be prepared to change your monitoring frequency as the

need arises.
You may also want to consider performance audits for applications that appear
to be running acceptably, but whose total resource consumption is large.

1.2.4 Responsibilities
Be prepared to develop a process that you can follow once a problem is
discovered. The main function of the process will be to identify who is
responsible for fixing the problem within an agreed time period.
Responsibilities can be assigned to:

• System programmers
• Performance specialists
• Database administrators
• Application developers
• Systems analysts
• Data storage specialists.
1.2.5 Active Traces

Input for DB2 PM reports is gathered through the DB2 trace facility. Because
data cannot be gathered retrospectively, you should plan to identify the types of
trace and the classes you want to have start automatically at DB2 initialization.
For most problem situations you will find that these classes provide all of the
required trace data:
• Accounting trace classes 1, 2, and 3
• Statistics trace classes 1 and 3
• Monitor trace classes 1, 2, and 3.
In addition to these trace classes you can consider starting accounting trace
classes 7 and 8, which report response times for packages. Class 7 reports the
CPU and elapsed times, and class 8 reports suspension times.
Note: To view data using the DB2 PM Online Monitor, you have to start monitor
trace class 1. When monitor trace class 1 is active, DB2 automatically starts
monitor trace classes 2 and 3, if accounting trace classes 2 and 3 are already
active. The destination of the monitor trace classes 2 and 3 is the same as the
destination of monitor trace class 1. Conversely, if only accounting trace class 1
is started, and whenever monitor trace classes 2 and 3 are started, DB2
automatically starts accounting trace classes 2 and 3. The destination of
accounting trace classes 2 and 3 is the same as the destination of accounting
trace class 1.
Some traces provide very detailed information, and we recommend that you
activate them only when accounting and statistics reports have identified a
specific problem requiring this level of detail. Reports showing high levels of
detail are by their nature expensive to run. Decide where the trace data is to be
collected. You may choose to collect the data in system management facility
(SMF), generalized trace facility (GTF), or a user-defined data set. The last option
would normally be for specific problem diagnosis. Ensure that your MVS
professional knows your intention with regard to SMF, as an increase in the SMF
buffers, size, and number of data sets may be required.
You should consider using GTF primarily for short-duration traces where the
data volume can be estimated fairly exactly or is not very large. Also it is
8 DB2 PM
generally easier to stop GTF tracing and make the data available than it is to
switch and dump the SMF data set.
See 4.3, “Collecting DB2 Performance Data” on page 68 for a more detailed
discussion on collecting DB2 PM data.
1.2.6 Reporting Methods

There are a number of methods for representing the data found in reports.
Consider carefully the most appropriate reporting method with regard to who will
read the report and the type and level of detail of the information required. DB2
PM can produce a variety of reports, tailored for specific needs. Professionals
who would be involved in performance management include system
programmers, database administrators, and systems analysts.
Each of these professionals looks at the system and/or application from a

different perspective. Therefore the following report structures may be
applicable:
• Graphs
• Tailored reports
• Exception reports.
The database administrator will be concerned with the performance of

transactions, whereas the system programmer will be interested in the overall
performance of the DB2 subsystem. From a periodic reporting point of view,
graphs easily convey trends and indicate either stability or ensuing problems.
The input for the DB2 PM graph function can be saved (SAVE) and reused
(RESTORE) to produce a longer-term view of an applications trend. Additionally
the database administrator may only be interested in certain fields within a
report. DB2 PM provides a facility to identify and produce reports containing
selected fields.
You may set exception thresholds for both batch reports and real-time
monitoring. These thresholds allow you to predefine exception conditions at the
thread and subsystem levels. An exception condition, in a real-time
environment, triggers a DB2 PM Online Monitor exception event. In a batch
reporting environment it is reported as an exception in an easy-to-read
preformatted accounting or statistics exception report. You can preserve for
future reference a record of the exception conditions that have occurred on the
system by using the DB2 PM FILE option of the accounting and statistics report
set. The FILE option enables you to collect the data meeting exception
conditions in a sequential data set that can be loaded into DB2 tables by
executing the LOAD utility. You can write SQL queries using a product such as
the Query Management Facility (QMF) to retrieve the data from these tables and
generate reports.
1.2.7 Measurements
Before you can begin monitoring you must know your performance objectives.
These objectives will differ among job responsibilities. For example, a system
programmer will have overall system performance objectives, and a database
administrator will have application-specific objectives.
Database administrators should attempt to identify the average resource

consumption and elapsed times of their most critical query transactions, update

transactions, and batch jobs. If the transactions are truly representative, you
may use these values as a barometer to check the health not only of the
application but of the DB2 subsystem as a whole.
Using Estimator you can obtain an estimate of the performance you expect for
representative queries. Then you can compare those estimates to actual DB2 PM
reports to see whether a tuning problem is making these queries consume more
resources than would be expected. Once a system is running, you can compare
current measurements from DB2 PM with previous measurements from DB2 PM.
The Estimator help file entitled “Estimated Results versus Measured Results”
assists you in comparing DB2 PM reported data with estimates from the
Estimator.
Key measurements from a system programmer perspective include:

• Environment descriptor manager (EDM) pool usage
• Data manager critical threshold reached
• Threads queued at create
• Lock escalations
• Sequential prefetch disabled
• Unavailable output log buffers
• Reads from archive logs
• Storage problems related to the buffer pool or hiperpool
• Constraints on query parallel execution.
Key measurements from a database administrator perspective include:

• Overall class 1 transaction time
• Class 3 wait time
• Lock and/or latch suspensions
• Number of getpages and number of getpages expected
• Buffer updates and number of updates expected
• Sequential prefetch requests and the number of sequential prefetches
expected
• Incremental binds
• Rid list processing
• Max locks held
• Deadlocks
• Timeouts
• Query parallelism enablement.
The expected number of getpages, updates, and sequential prefetches can be

validated by examining the objectives established at the internal design stage.
In addition consider exception profiling as a method of obtaining average values
for getpages, updates, and sequential prefetches. For more information on
exception profiling see 3.7, “Exception Profiling” on page 49.
10 DB2 PM
Once you have obtained realistic and typical values, you can begin the business
of developing exception thresholds. Do not underestimate the power of this
function. Exception processing, if used correctly, forms the central hub of your
monitoring strategy.
1.2.8 Actions
Determine the actions required after the discovery of either an unacceptable
trend or a problem situation. First assess how pervasive the problem is. Is it
systemwide, or application specific?
In an ideal world plan for your actions to be nondisruptive to the system.

Attempt to preserve the Service Level Agreement. Use exception monitoring to
achieve that goal.
Plan to be notified when a situation is developing but has not yet reached
problem status. By using both periodic and event monitoring, with the exception
function active, you can achieve that goal. Define warning and problem
thresholds. The setting of these thresholds, specifically warning thresholds,
allows you to detect situations before they become critical problems.
The identification of a warning situation, although not critical, may require further
investigation. Use the DIAGNOSE command from the Thread Detail panel of the
DB2 PM Online Monitor for online diagnosis of the principal factors affecting the
thread′s performance. After consideration you may decide that a more detailed
review of the problem is required, and that additional traces should be started.
DB2 PM can schedule the activation of nominated traces by a trigger. The trace
can be triggered by time, by the detection of a specific exception, or
immediately. It can be configured to stop after a specific time, after a
predetermined number of records have been collected, at thread termination, or
following the collection of a particular instrumentation facility component
identifier (IFCID) records a specified number of times. This additional data
enables a more detailed examination of the problem.
When you find that there are performance problems when you are monitoring
the system, you can use various panels and reports to investigate the cause of
the problems.
If you are using periodic exception processing in the Online Monitor and you are
notified about a problem, the best way to find out what caused it is to examine
the thread activity panels, especially diagnostic view, and explain, or statistics
and system parameter panels, depending on the type of problem.
Figure 2 on page 12 is a road map of problems detected in periodic exception

monitoring.

------------- ------------------------
| System | |Statistics and system |
|-------->| problem |----->|parameter panels |
------------ | | | | |
|Problems | | ------------- ------------------------
|found in | |
|periodic |-----|
|exception | |
|monitoring| | ------------- ------------------------
------------ | |Application| |Thread activity |
|-------->| problem |----->|panels, and explain |
| | | |
------------- ------------------------
Figure 2. Road Map of Problems Found in Periodic Exception Monitoring
If you are doing EVENT exception monitoring, and the DB2 PM Online Monitor
panels do not provide adequate information to determine the cause of the
problem, you should produce SQL activity, locking, or I/O activity reports.
Figure 3 is a road map of problems detected in EVENT exception monitoring.
-----------------------
|-------->| SQL activity reports|
------------ | -----------------------
|Problems | |
|found in | | -----------------------
|EVENT |------|-------->| Locking reports |
|exception | | -----------------------
|monitoring| |
------------ | -----------------------
|-------->| I/O activity reports|
-----------------------
Figure 3. Road Map of Problems Found in EVENT Exception Monitoring
If you use the accounting and statistics exception reports to monitor your
system, you can often detect the cause of a performance problem using the
comprehensive information they offer. You should produce these reports using
the TOP option in accounting or the INTERVAL option in both accounting and
statistics so that you can immediately focus on potential problem areas.
Sometimes, however, you require more detailed reports to determine the exact
cause of the problem.
12 DB2 PM
Figure 4 on page 13 is a road map of problems detected in exception reports.
---------------------
|Statistics, |
------------- |I/O activity, |
| System | |locking activity, |
|-------->| problem |----->|utility activity |
------------ | | | |or record trace |
|Problems | | ------------- ---------------------
|found in | |
|exception |------|
|reports | | ---------------------
------------ | ------------- |Accounting,explain,|
| |Application| |accounting TOP, |
|-------->| problem |----->|SQL activity, |
| | |locking activity, |
------------- |utility activity or|
|record trace |
---------------------
Figure 4. Road Map of Problems Found in Exception Reports
1.2.9 Monitoring Recommendations

In conclusion, to develop a successful monitoring policy, we recommend that
you:
• Set realistic exception thresholds
• Define your monitoring scope
• Agree on who will be responsible for monitoring and problem resolution
• Plan to review exception reports daily
• Start only those traces that are appropriate
• Periodically review your problem diagnosis strategy and be prepared to
adjust it as environmental and business conditions change.

14 DB2 PM
Chapter 2. DB2 PM Monitoring Facilities
This chapter describes the facilities that DB2 PM offers to monitor your DB2
subsystem. It also identifies who can use these facilities
A DB2 subsystem can generate large amounts of trace data used in monitoring.
DB2 PM offers facilities to reduce the volume of data, for example, you can filter
the information shown on reports, selecting data only about certain plans within
specified times. This chapter also describes those reduction facilities.
2.1 DB2 PM Online Monitor

The DB2 PM Online Monitor presents a current view of various aspects of an
active DB2 subsystem, including applications in use, on a set of interactive
panels. You can view the DB2 performance information in a form that is easy to
understand and analyze.
Using the DB2 PM Online Monitor you can identify whether changes made to an
application or the DB2 subsystem enhanced or degraded performance. You can
also identify areas where tuning is required.
You can use the DB2 PM Online Monitor to obtain information about:
• Subsystem-wide activity
− CPU times
− Buffer pool use
− Locking
− I/O activity.
• Individual thread activity
− Elapsed time
− Time spent in DB2
− Duration of suspension
− Read and write activity
− Locks obtained
− SQL statements executed.
Using the DB2 PM Online Monitor history function you can capture snapshots of
subsystem and/or thread activity and display the information at any point in time.
To use the DB2 PM Online Monitor, ensure that the DB2 monitor trace is active.
The DB2 PM Online Monitor requires monitor trace class 1 to collect data.
Table 1 shows the classes that you should activate to use the DB2 PM Online
Monitor.
Table 1 (Page 1 of 2). Monitor Trace Classes

Class Description
1 Activate synchronous data collection
2 DB2 CPU and elapsed time for the thread activity

Table 1 (Page 2 of 2). Monitor Trace Classes
Class Description
3 DB2 suspension times for the thread activity
7 DB2 CPU and elapsed time for the package or DBRM
8 DB2 suspension times for package or DBRM
Refer to the IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4
Online Monitor User ′ s Guide , Chapter 6, “Using the Online Monitor” for the
privileges required.
To access the DB2 PM Online Monitor, select option 3, View online DB2 activity,
from the IBM database 2 Performance Monitor panel (see Figure 5).
IBM Database 2 Performance Monitor

Command ===> ___________________________________________________________
Select one of the following.
__ 1. Create and execute DB2 PM commands

2. Display and print graphs
3. View online DB2 activity
4. Maintain parameter data sets
5. Customize DB2 PM report and trace layouts
6. Exception profiling
F1=Help F3=Exit F6=History F12=Cancel
Figure 5. IBM Database 2 Performance Monitor Panel
Figure 6 on page 17 shows all of the options you can access from the DB2 PM
Online Monitor Main Menu.
16 DB2 PM
DB2 PM Online Monitor Main Menu
__ 1. Display Thread Activity

2. Display Statistics
3. Display System Parameters
4. Options
5. Control Exception Processing
6. Collect Report Data
7. IRF - Create and execute DB2 PM commands
8. IRF - Display and print graphs
9. IRF - Maintain parameter data sets
10. Explain
Command ===> ____________________________________________________________

F1=Help F3=Exit F12=Cancel
Figure 6. DB2 PM Online Monitor Main M e n u
The four major functions of the DB2 PM Online Monitor are:

• Thread activity
You can view detailed thread and locking information for all connected
threads to your DB2 subsystem. You can also view active threads in
summary format, where all active threads are displayed, or examine them
individually in more detail.
• Subsystem statistics
You can view the overall efficiency of your DB2 subsystem. Important
statistics and performance ratios are displayed in a summary or detailed
format.
• Configuration setting
Using option 3, Display System Parameters, you can view how DB2 is
currently configured. Any dynamic change made (for example, to the buffer
pool size) is immediately reflected. If the data collector is active, you can
use the HISTORY command to go back to an earlier point in time and display
the previous settings.
• Controls and filters
The DB2 PM Online Monitor controls and filters help you diagnose
performance problems. You can choose for display only the threads that you
are interested in monitoring and control the sequence in which they are
displayed by using the QUALIFY and SORT commands, or the appropriate
Program Function keys on the Thread Summary panel. You can use the
Exception Processing facility and have the problems highlighted while the
thread is displayed. You can get to the SQL Statement and DBRM or SQL
Statement and Package panel from the Thread Detail panel that you are
Chapter 2. DB2 PM Monitoring Facilities 17

viewing and invoke Explain to analyze the access path and processing
methods used in the execution of the SQL statement currently executing.
2.2 Exception Processing

Exception processing provides you with the capability to identify performance
problems, displaying DB2 threads and statistics fields that contain values outside
the limits you have specified. Those limits are the threshold values for thread
activity and statistics specified in the exception threshold data set .
The DB2 PM Online Monitor LOOK command allows you to view information for
any of the exceptions detected.
You can create data sets where the exception processing output data can be
written for later analysis. The exception log data set contains an entry for each
field found in exception status. You can either print the contents or load the
same into a DB2 table for further analysis. The DB2 PM output data set
(DPMOUT) contains the DB2 instrumentation records sorted and converted to a
format that can be used to create DB2 PM reports, traces, and data sets.
There are three basic modes of exception processing:

• Display exception processing
The display exception processing mode operates in the foreground of DB2
PM Online Monitor processing. It allows you to view thread activity, and
statistics exceptions in interval or delta processing mode. Figure 7 on
page 19 shows how to invoke display exception processing.
History can be active simultaneously with either interval or delta processing
mode. Use the statistics INTERVAL command and statistics DELTA command
in conjunction with History to get a clear idea of the resource utilization
between any two points in time.
Refer to the IBM DATABASE 2 Performance Monitor for MVS (DB2 PM)
Version 4 Online Monitor User ′ s Guide , Chapter 12, “Viewing DB2 Statistics”
for an explanation of delta and interval processing.
• Periodic exception processing
The periodic exception processing mode operates in the background of DB2
PM Online Monitor processing. It allows you to view thread activity, and
statistics exceptions that occurred when the periodic monitoring interval
specified has elapsed.
Figure 7 on page 19 shows how to invoke periodic exception processing.
18 DB2 PM
Exception Processor
For any field enter any character to activate
Activate/Deactivate Exception Processing

/ Display thread summary
/ Display thread detail
_ Display statistics detail
/ Periodic
Options
Periodic units . . . . . . . . . . . . . . 2 1=Seconds
2=Minutes
Periodic interval . . . . . . . . . . . . 10 1-7200 Seconds
1-120 Minutes
> Disable auto-display for problem exceptions
> Sound alarm for exception warnings
_ Log file data set output needed
_ DPMOUT data set output needed
Exception threshold data set

Name . . . . . . . . . ¢SAMPLE.EXCEP.THRESH01¢_________________________
Command ===> ___________________________________________________________

F1=Help F3=Exit F7=Up F8=Down F12=Cancel
Figure 7. Exception Processor Panel
If the data collector is active, periodic exception processing can continue

when you exit the DB2 PM Online Monitor or log off TSO.
If the data collector is not active, periodic exception processing terminates
when you exit the DB2 PM Online Monitor.
• Exception event processing
The exception event processing mode operates in the background of DB2 PM
Online Monitor processing. It is triggered by the presence of user-specified
events. You can monitor the following events:
− Deadlock
− Timeout
− EDM pool full
− Authorization failure
− Thread commit indoubt.
When an exception event is detected, the Exception Notification window is
displayed to notify that an exception event has occurred.
The EXCEPTIONEVENT data collector parameter must be specified before

exception event processing be activated.
Refer to the IBM DATABASE 2 Performance Monitor for MVS (DB2 PM)
Version 4 Online Monitor User ′ s Guide , Chapter 19, “Data Collector Purpose
and Function,” for details.
Note: If your installation has installed the DB2 PM Online Monitor
without the data collector, exception event processing is

not available.
2.3 Explain
The explain function provides specific help in identifying access path problems.
It also helps with the writing of efficient SQL statements through prototyping
during application development.
With the explain function you can identify in an easy to read format the access
strategy chosen by DB2 for a given SQL statement.
The distributed explain function lets you explain remote queries in the DB2 PM
Online Monitor environment.
Explain can be run against:

• Currently executing SQL statement
• Specified SQL statement
• SQL statement within a given database request module (DBRM)
• SQL statement within a given package
• SQL statement with a given query number.
You can explain an SQL statement from:

• Any thread diagnosis panel or the DB2 PM Online Monitor panel displaying
the SQL statement
• Option 10, Explain, from the DB2 PM Online Monitor Main Menu (see
Figure 6 on page 17)
• ISPF/PDF editor
Use the Source Explain Options panel (Figure 8 on page 21) to specify the
source explain processing options.
20 DB2 PM
DGOMYWSO Source Explain Options
Enter/Change the source explain options then press

Enter to continue.
Local DB2 Subsystem. . . . . . . . . . . . DB2F

Current Server Location . . . . . . . . . ST11DB2F________
Current SQLID . . . . . . . . . . . . . . DB2RES3___
Query number . . . . . . . . . . . . . . ____________
/ Set current degree to ANY
1 Display this window
Define Source Language . . . . . . . . . . 7 1. Assembler
2. C/370
3. COBOL
4. FORTRAN
5. PL/1
6. REXX
7. SPUFI
F1=Help F2=Split F3=Exit F9=Swap F12=Cancel
Figure 8. Source Explain Options Panel
2.4 HISTORY Command

The HISTORY command enables you to go backward in time to display thread
activity, statistics, and system parameters.
You can only view past data if the data collector is active for the subsystem you
are monitoring. The date and time on the panels supporting history indicate
when data being displayed was collected.
The history data is gathered at installation-defined intervals, and it is kept in a

VSAM data set or data space as specified. When the data set or data space is
full, history data is written to the beginning of the data set or data space, writing
over the data gathered earlier.
The availability of data is limited by the collection rate, the size of the VSAM
data set or data space used, the amount of historical data to be maintained, and
the thread history qualifications defined to limit the data gathered.
2.5 DIAGNOSE Command

You can issue the DIAGNOSE command from most thread activity panels. The
diagnostic view function of the DB2 PM Online Monitor analyzes thread
performance data and indicates the principal factors influencing a thread′ s
performance. For thread diagnosis, monitor trace classes 1, 2 and 3 must be
started. Additional diagnostic information is provided when data for accounting
trace classes 7 and 8 is available.

You can also use the DIAGNOSE command against historical data (see Figure 9
on page 22). The date and time when the data was collected are displayed.
The diagnostic analysis is based on a number of rules, some of which use

thresholds that you can adjust if necessary. These rules are referred to as rules
of thumb. Refer to the IBM DATABASE 2 Performance Monitor for MVS (DB2
PM) Version 4 Online Monitor User ′ s Guide , Chapter 17, “Customizing Thread
Diagnosis” for details.
95/04/24 17:30 Diagnosis of Thread DB2RES2 DSNTEP41 DSNTEP

Command ===> __________________________________________________________
HISTORY 95/04/24 14:10
_ The buffer pool read hit ratio for BP0 is low

_ The thread has experienced lock escalations
Distribution of DB2 elapsed time (%):

_ Synchronous I/O . . . . . . . . . . . . . . . . . . . . . : 59
_ Actively processing . . . . . . . . . . . . . . . . . . . : 38
_ Waiting for system resources . . . . . . . . . . . . . . : 1
_ Services . . . . . . . . . . . . . . . . . . . . . . . . : 0
_ Other read I/O . . . . . . . . . . . . . . . . . . . . . : 0
DB2 elapsed time in the current DBRM or package (%) . . . . . : 100

Thread elapsed time inside DB2 (%) . . . . . . . . . . . . . : 100
Thread active processing inside DB2 (%) . . . . . . . . . . . : 100
Figure 9. Diagnosis of Thread Window
2.6 Collect Report Data

With the Collect Report Data option you can gather data for specific DB2 PM
Batch report sets for immediate diagnosis. You are not required to have any
knowledge of which DB2 traces need to be started for these specific report sets.
You can collect the DB2 trace data in a user-defined data set, and there is no
need to bother about SMF or GTF. Data collection can be automatically started
and stopped on the basis of time periods or events of interest. You can also
view the status of traces and messages.
To access collect report data panels, select option 6, Collect Report Data, from
the DB2 PM Online Monitor Main Menu (see Figure 6 on page 17).
To collect performance data, you first have to configure a collect task. You can
configure and start up to four collect tasks. For each collect task you must
specify:
• The type of data you want to gather
Select the DB2 PM report sets for which you want data to be collected. A
DB2 trace is started for each report set selected. You can collect data for
the following report sets:
− Accounting
22 DB2 PM
− Audit
− I/O Activity
− Locking
− Record Trace
− SQL Activity
− Statistics
− System Parameters
− Utility Activity.
See Appendix A, “DB2 Trace Data As Input to DB2 PM Report Set” on
page 183 for the DB2 trace data required for the various DB2 PM report sets.
You can also collect specific data types, IFCIDs, and limit the data by
requesting location, plan name, and authorization ID.
• Trace start and stop criteria
When the criteria are met the collect task is automatically started or stopped.
The criteria to start collecting data can be, for example, time, periodic
exception, exception event. The criteria to stop collecting data can be
elapsed time, number of records collected, thread termination, or a specified
number of records collected for a specific IFCID.
• Output data set name
To begin the triggering of DB2 traces, you must start the collect task. To stop
DB2 traces you must stop the collect task. When the traces are stopped, the
data collected in the output data set is available to DB2 PM Batch.
2.7 DB2 PM Batch

You use DB2 PM Batch facility for more in-depth performance analysis. The DB2
PM Batch output is grouped into report sets associated with a particular type of
data. Each report set shows performance data at different levels of detail and
for different areas of performance. DB2 PM Batch provides three major types of
output for systemwide and application-related information:
• Traces and reports
• Data sets
• Graphs.
Systemwide performance data shows CPU times, buffer pool usage, locking, and
log and I/O activity. For an application you can find out the elapsed time, the
time spent in DB2, the read and write activity, the locks obtained, and the SQL
executed.
Problem situations can be broadly divided between system and application

problems. The accounting and statistics reports, showing only exception cases,
help to identify where problems lie. However, if necessary, you may have to get
more detailed reports.
The accounting and statistics reports can be tailored.

2.7.1 Report Sets
Following are the DB2 PM Batch report sets:
• Accounting
Presents DB2 resource usage for a given thread ordered by DB2 PM
identifiers.
• Audit
Presents information about authorization and the users of specific resources.
• Explain
Presents information about the access path selected by DB2 for a particular
SQL statement, an application package, an application plan, a saved Query
Management Facility (QMF) query (SQL format), and a specified query
number.
• I/O activity
Presents information about I/O activity for the buffer pool manager, the
environmental descriptor manager (EDM), and the DB2 log manager.
• Locking
Presents information about lock requests, lock suspensions, lockouts,
timeouts, and deadlocks.
• Record trace
Presents individual trace records formatted into readable report entries. It is
used for a very detailed study of a problem when none of the other reports
listed can identify the cause.
• SQL activity
Presents information about the execution of SQL statements during the
processing of a DB2 application.
• Statistics
Presents information about systemwide performance. Statistics reports can
be used to determine the efficiency of the subsystem, and they often indicate
the problem area.
• System parameters
Presents information about the configuration of the DB2 subsystem being
monitored. It is very important to tune the system parameters because the
values set for these parameters directly affect performance.
• Utility activity
Presents information about DB2 bind and utility activity.
24 DB2 PM
DB2 PM offers various ways of identifying unusual situations and therefore
limiting the amount of data that you need to examine. You can filter the data
and highlight potential problems using:
• From/To processing
To show information only for certain specified times.
• Include/Exclude processing
To show information only for certain plans, authorization IDs, or locations.
• Exception processing
To show only those entries that have values outside expected or planned
limits. DB2 PM compares the values of certain fields in the input data with
the exception thresholds and highlights any values that do not fall within
these limits.
• Accounting TOP option

To list, at the end of an accounting report or trace, threads or users that
have required the greatest use of the resources specified in the TOP option.
The TOP lists indicate which entries on the report have the highest value in
the field you have specified. You can use the TOP ONLY option to filter the
input data. With this option, only entries that contain the highest values for
the TOP field are shown.
• Ordering by INTERVAL
To summarize data for the peak periods during the day. You can use it in
accounting and statistics report sets.
• SQL activity SORTBY and SUMMARIZEBY options

To highlight potential problems by sorting and summarizing the information.
For example, a problem cursor can be identified by summarizing SQL activity
by cursor and ordering the cursor operations related to that cursor by task
control block (TCB) times.
• Deadlock and timeout traces

Use the deadlock and timeout traces to monitor locking activity. As these
traces use DB2 statistics trace data as input, they do not result in significant
performance overhead. We recommend that you run them regularly.
2.7.2 Traces and Reports

Traces show individual DB2 events, such as accounting for a particular thread,
thread terminations, grants of privileges, deadlocks, and utility executions. All
events are listed individually, usually in the order of occurrence.
Reports show these events summarized by DB2 PM identifiers, such as primary

authorization ID or plan name. You can, for example, order an accounting report
by plan name if you want to see all threads summarized for every individual
plan.

2.7.3 Data Sets
DB2 PM formatted data can be stored in data sets suitable for loading into DB2
tables. The data in DB2 tables can be used, for example, to produce tailored
reports using a reporting facility such as QMF.
DB2 PM offers two ways of producing data sets:

• FILE subcommand
FILE writes instrumentation data to a data set that can be directly loaded into
DB2 tables. It is available in the statistics, accounting, audit, and locking
report sets.
• SAVE subcommand
SAVE saves summarized accounting and statistics data into a VSAM data
set. You can use the DB2 PM Save-file utility to convert the data set to a
format that is suitable for loading into DB2. You should also use SAVE to
produce graphs.
2.7.4 Graphs
You can generate and view graphs online by using the Interactive Report Facility
(IRF). You can create graphs from saved accounting and statistics data or from
frequency distribution data. Graphs are especially useful in determining trends
in DB2 performance.
The following graphs are available:
• Accounting by field identifiers

To analyze the performance of one group of transactions over a time interval
to determine trends.
• Accounting by DB2 PM identifier

To analyze the performance of up to four groups of transactions
(combinations of, for example, primary authorization IDs and plan names) for
one field over a period of time. You can use this graph to determine
whether one transaction is adversely affecting another.
• Statistics
To analyze DB2 system performance over a period of time. You can use this
graph to monitor systemwide DB2 usage trends.
• Frequency distribution
To analyze the frequency at which a field is between certain values. You can
generate this graph for selected fields from accounting, I/O, locking, SQL
activity, and utility activity data. It helps you identify unusual values by
dividing events into ranges.
26 DB2 PM
2.8 Interactive Report Facility
Using the IRF you can:
• Generate the JCL to invoke the DB2 PM facilities and submit the job
• Tailor accounting and statistics reports and traces
• Produce graphical reports.
Maintain the following parameter data sets:

• Exception thresholds
• Correlation translations
• Time zone information
• MAINPACK definitions.
Batch User ′ s Guide , Chapter 8, “Customizing DB2 PM Functions” for details.
2.9 Who Can Use DB2 PM Facilities?

Database administrators, system programmers, application analysts, auditors,
and capacity planners require performance information from DB2 for different
purposes. For example, application analysts on the one hand are interested in
determining the CPU resource consumption of SQL statements so that they can
design the statements to optimize resource utilization. On the other hand,
system programmers are interested in tuning the overall system to meet
response time and transaction rate criteria. These differences in purpose
require different DB2 PM report sets, as described below.
The following professionals are typically involved in a performance evaluation:

• Application developers
Application developers require information that can assist with determining
the efficiency of application-related SQL. Therefore the DB2 PM report sets
that they require are transaction-related. The reports of interest are:
− Accounting
− Statistics
− SQL activity
− Explain.
• Capacity planning
Capacity planners require information that can assist in monitoring changes
in resource requirements from a systemwide perspective. Capacity planners
have overall responsibility for all computer resources, such as CPU, DASD,
storage, or network. Monitoring the system regularly is critical for learning
about the company′s growth pattern as well as tracking any changes to the
system utilization. The reports of interest to capacity planners are:
− Accounting
− Statistics
− I/O activity.

• Database administrators
Database administrators require information that can assist in estimating the
DASD and CPU resources that the databases, utilities, and SQL will need.
They are involved in all phases of development, from the requirements
phase through moving the application into production. Thus they require a
wide range of report sets. The reports of interest are:
− Accounting
− Audit
− I/O activity
− Locking
− Record trace
− Statistics
− System parameters
− Utility activity.
To monitor DB2 system performance and correct any potential problems
before or as they occur, operations personnel require online systemwide
information that can assist with detecting any potential problem areas. If
there are problems with any resource, operations notifies the system
programmer for diagnosis purposes and the capacity planner for estimation
purposes. This information is provided by DB2 PM Online Monitor. The
panels of interest are:
− Thread activity
− Locking activity
− Statistics.
• System programmers
System programmers require information that can assist in monitoring
overall DB2 system performance and diagnosing problems. System
programmers monitor the system resource utilization for buffer pools, EDM
pools, DB2 address spaces, log data sets, and bootstrap data sets. The
reports of interest are:
− I/O activity
− Locking
− Record trace
− Statistics
− System parameters
− Utility activity.
• Network specialists
Some aspects of overhead processing, for instance, network processing, are
not under DB2 control. Network specialists are responsible for the
28 DB2 PM
performance of the network that supports online transactions. In a
distributed application environment, network specialists must tune VTAM to
improve the performance of the network.
Monitoring and tuning performance in a distributed environment is a
complex task involving knowledge of several products. Refer to the IBM
DATABASE 2 for MVS/ESA Version 4 Administration Guide for some
guidelines on improving the performance of distributed applications.

30 DB2 PM
Chapter 3. Using DB2 PM for Exception Processing
Exception processing is the most effective way of identifying performance

problems. The initial step in monitoring your DB2 system should always be
exception processing.
Exception processing is a passive task and should be regarded as a background

event. The DB2 PM Online Monitor and exception processing are not designed
to dominate your time; on the contrary, the monitoring process should be
invisible until a problem is reported.
There are two distinct forms of exception processing:

• Batch exception processing
• DB2 PM Online Monitor exception processing.
Batch exception processing identifies exception conditions that have occurred in

the past and uses input data from sources such as SMF or GTF. DB2 PM Online
Monitor exception processing is a real-time activity and notifies you at the time
the exception occurs. The main difference between DB2 PM Online Monitor and
Batch exception processing is that DB2 PM Online Monitor exception processing
allows you to get involved in a problem a little before users start complaining.
This time buffer enables you to start diagnosis of the problem and convey to
users that you are in control of the situation.
Use DB2 PM Online Monitor exception processing to identify DB2 thread activity
and statistics fields that contain values outside the limits you set. Through the
early identification of problems before critical thresholds have been reached you
can better manage service levels.
Using display and periodic exception processing, which are discussed in detail in
this chapter, you can monitor and identify threads that are experiencing
problems and subsystem events that might be causing performance degradation.
Using exception event processing, which is discussed in detail in this chapter,

you can monitor for the presence of particular events.
The threshold values for thread activity and statistics fields are specified in the
exception threshold data set. A threshold can be defined as a warning or a
problem . When exception events are detected during your monitoring session,
you are notified so that you can take appropriate action.
To view the information about any of the exceptions use the DB2 PM Online
Monitor LOOK command.
With exception processing, you can create the following two data sets for later
analysis:
• Exception log file data set
• Exception DPMOUT data set.

3.1 Exception Modes
DB2 PM Online Monitor exception processing provides you with three distinct
modes of operation. These modes are exception event processing , periodic
exception processing , and display exception processing .
3.1.1 Exception Event Processing

By activating exception event processing you monitor the system for the
following events:
• Deadlock
• Timeout
• EDM pool full
• Authorization failure
• Thread commit indoubt.
The process runs as a background task within the DB2 PM Online Monitor
provided the data collector is active. When an exception is detected the
Exception Notification window is displayed to notify that an exception has
occurred. DB2 PM predefines the events to be monitored; you cannot make your
own additions. However, you can make modifications to include or exclude
events from the list for exception event processing.
You can select events from within the DGOVDCCS member in the
product-supplied SDGOSAMP data set or from the Data Collector Parameters
panel. For further information on setting event exceptions in the DGOVDCCS
data set refer to the IBM DATABASE 2 Performance Monitor for MVS (DB2 PM)
Version 4 Online Monitor User ′ s Guide , Chapter 19, “Data Collector Purpose and
Function.”
Figure 10 on page 33 depicts the Exception Event Summary panel. All exception
events are written to this panel, which shows the date and time of the event, the
IFCID, and type of exception encountered.
32 DB2 PM
Look Selections
-----------------------------------------------------------------------------.
| Exception Event Summary ROW 1 TO 5 OF 8 |
| Command ===> ________________________________ |
| _ |
| |
| Reporting Started . . . . . . . . . . . : 95/04/24 08:07:11 |
| Last Interval . . . . . . . . . . . . . : |
| |
| Date Time IFCID |
| _ 95/04/19 16:58:47 196 |
| Timeout |
| |
| _ 95/04/19 18:52:17 196 |
| Timeout |
| |
| _ 95/04/19 19:01:47 196 |
| Timeout |
| |
| _ 95/04/19 19:12:02 196 |
| Timeout |
| |
| _ 95/04/19 19:25:47 172 |
| Deadlock |
| F1=Help F3=Exit F7=Up F8=Down F12=Cancel |
¢-----------------------------------------------------------------------------¢
Figure 10. Exception Event Summary Panel
When you select, for example, the deadlock event on the summary panel,
another panel is displayed that contains detailed information about the exception
event (see Figure 11 on page 34), such as the holder and waiter of the
resources, state and duration of the lock, and lock resources. The names of the
lock resources in this case are displayed as database IDs (DBIDs) and page set
IDs (PSIDs) and can be resolved by reference to SYSIBM.SYSTABLESPACE. For
other object types, for example, indexes, refer to the appropriate DB2 system
catalog tables.
Chapter 3. Using DB2 PM for Exception Processing 33

Look Selections
-----------------------------------------------------------------------------.
-----------------------------------------------------------------------------
| Deadlock Data |
| Command ===> ____________________________________ |
| _ |
| THERE IS NO ADDITIONAL INFORMATION ABOVE THIS LINE. |
| More: + |
| IFCID . . . . . . . . . . . . . . . . . : 172 |
| |
| Number of resources involved in deadlock : 2 |
| Deadlock interval counter . . . . . . . : 2 |
| Time deadlock detected . . . . . . . . . : 19:25:47 |
| |
| Locked resource |
| Type . . . . . . . . : DATAPAGE |
| Name . . . . . . . . : Database : 4 Object : 14 |
| Page # : X¢000002¢ |
| |
| Holder |
| Member/DBMS identifier . . . . . . . . . : DB2F |
| Plan name . . . . . . . . . . . . . . . : DSNESPCS |
| Correlation identifier . . . . . . . . . : DB2RES3 |
| Connection identifier . . . . . . . . . : TSO |
| LUW identifier . . . . . . . . . . . . . : USIBMST .ST11DB2F.AAF2184A7E24 |
| State . . . . . . . . . . . . . . . . . : X |
| Duration . . . . . . . . . . . . . . . . : COMMIT |
| |
| Attributes |
| CBS/RS . . . . . . . . . . . . . . . . : N |
| PRIVATE . . . . . . . . . . . . . . . : N |
| RESTART . . . . . . . . . . . . . . . : N |
| MODIFY . . . . . . . . . . . . . . . . : N |
| |
| Waiter |
| Member/DBMS identifier . . . . . . . . . : DB2F |
| Plan name . . . . . . . . . . . . . . . : DSNESPCS |
| Correlation identifier . . . . . . . . . : DB2RES2 |
| Connection identifier . . . . . . . . . : TSO |
| LUW identifier . . . . . . . . . . . . . : USIBMST .ST11DB2F.AAF218380BF9 |
| Requested function . . . . . . . . . . . : LOCK |
| State . . . . . . . . . . . . . . . . . : S |
| Duration . . . . . . . . . . . . . . . . : MANUAL |
| DB2 assigned worth value . . . . . . . . : 18 |
| |
| Attributes |
| CONDITIONAL . . . . . . . . . . . . . : N |
| AUTO-RELEASE . . . . . . . . . . . . . : N |
| CBS/RS . . . . . . . . . . . . . . . . : N |
| PRIVATE . . . . . . . . . . . . . . . : N |
| RESTART . . . . . . . . . . . . . . . : N |
| MODIFY . . . . . . . . . . . . . . . . : N |
| FORCE . . . . . . . . . . . . . . . . : N |
¢-----------------------------------------------------------------------------¢
Figure 11. Exception Event Summary Panel: Deadlock Data
34 DB2 PM
3.1.2 Periodic Exception Processing
Periodic exception processing runs as a background task, allowing you to
periodically monitor both thread activity and statistics fields. The warning and
problem thresholds set by you in the exception threshold data set are tested for
exceptions whenever the interval specified elapses. If the data collector is
active, periodic exception processing can continue when you exit the DB2 PM
Online Monitor or log off TSO.
When you next use the DB2 PM Online Monitor, any periodic messages reported
while you were logged off are displayed. Periodic exception processing is not
terminated until you stop it or until the data collector itself is stopped. If the data
collector is not active, periodic exception processing terminates when you exit
the DB2 PM Online Monitor.
Figure 12 shows a sample periodic exception processor panel indicating that

periodic exception processing is activated, periodic units are set to 1, denoting
second intervals, and the periodic interval is set to 30.
Exception Processor ST11DB2F DB2F V4
Command ===> ______________________________________

_ Display thread summary
_ Display thread detail
> Periodic
_ Exception event notification
Options
2=Minutes
1-120 Minutes

Name . . . . . . . . . ¢DB2RES2.THRESH1¢
Figure 12. Periodic Exception Processor Panel
In the example, every 30 seconds, the periodic exception processor takes a

snapshot and checks the DB2 instrumentation records against the values stored
in the exception threshold data set.
You should consider carefully the setting of the time interval and the unit for
which exceptions are checked. It is possible to miss exceptions in the DB2 PM

Online Monitor environment if the exception does not span periodic intervals
(see Figure 13 on page 36).
T1 T2 T3 T4
|____________________|____________________|____________________|
| | | | | |
| D1 | | D2 |
| | | |
P1s P1e P2s P2e
T5 T6 T7 T8
|____________________|____________________|____________________|
| | |
| D3 |
| |
P3s P3e
Figure 13. Periodic Exception Reporting
In the example time intervals T1 through T8 represent individual 30 second

periods and are the precise points in time when the periodic exception monitor
checks instrumentation data values against values in your exception threshold
data set.
For this example let us assume that the exception threshold data set contains
one value, checking for class 1 elapsed time, and the problem threshold is set to
> 4 . Therefore if the class 1 elapsed time exceeds 4 seconds, a problem
exception condition is raised. The interval is set from the Exception Processor
panel by specifying periodic units = 1 (seconds) and periodic interval = 30 (see
Figure 12 on page 35).
P1s, P2s, and P3s refer to the relative starting point of three transactions (P1, P2,
P3), and P1e, P2e, and P3e refer to the termination of the transactions.
Transaction P1 starts after time T1 and exceeds the threshold of 4 seconds at D1
before the second reporting interval, T2. In this case, even though the exception
threshold has occurred, a periodic exception is not reported, because the
transaction terminates before the second reporting period, T2.
Transaction P2 starts after time period T2 and exceeds the threshold of 4

seconds at D2 before time period T3. The transaction terminates after time
36 DB2 PM
period T3. This exception is reported by the periodic exception monitor precisely
at time period T3 because the exception event occurs before time period T3 and
the transaction is active during the time spanning T3.
Finally transaction P3 starts after time period T5 and progresses past time period
T6 and T7 where it exceeds the threshold of 4 seconds. At time period T8 the
periodic exception monitor does not report an exception condition because the
transaction terminates before the precise reporting interval, T8.
From the example you can see that it is important to consider the periodic
interval at which thresholds are checked. Different types of processing have
distinct time profiles; batch jobs typically have much longer elapsed times than
online transactions. You may want to use this model as a starting point to
develop the kind of thresholds that are important to your installation and the
periodic time interval that is appropriate for those thresholds.
You can evolve or develop an exception threshold data set that contains
thresholds targeted at a wide profile of job types, online transactions, batch,
query processing, and utilities or populate an exception threshold data set that is
more specific. It may be appropriate during certain periods of the day to have
different threshold data sets specified as the input to periodic checking.
DB2 PM Online Monitor periodic exception reporting can miss exceptions as

illustrated in Figure 13 on page 36. Therefore, as a general rule, the smaller the
periodic monitoring units (seconds), the smaller the possibility of missing an
exception event. Be aware, however, that when you reduce the periodic
monitoring cycle, you increase the CPU overhead.
3.1.3 Display Exception Processing

With display exception processing you monitor exception conditions according to
the values in your exception threshold data set. Display exception processing
runs in the foreground. You can be notified of exceptions while you are in the
Thread Summary, Thread Detail, or Statistics Detail panel, depending on the
options you choose at exception processor initialization. If you choose Display
thread detail , unless you are in the Thread Detail panel, you are not notified of
exception situations, nor is a record of the exception conditions displayed when
you issue the LOOK command.
If you decide to monitor at the thread summary level, when you display the
Thread Detail panel, exceptions are not reported. Be aware of this when
choosing either the Display thread summary or Display thread detail option. We
recommend that you choose the Display thread summary option which displays
all threads in either warning or problem status. Refer to the IBM DATABASE 2
Performance Monitor for MVS (DB2 PM) Version 4 Online Monitor User ′ s Guide ,
Chapter 9, “Exception Processing” for more information on the LOOK command.
Display exception processing differs slightly from periodic exception reporting

with respect to time intervals. Display exceptions are checked each time you
press Enter, so you determine the reporting interval by the frequency of your
action. To monitor using a consistent time period consider the AUTO display
command.
The AUTO display command simulates pressing Enter each time the period
specified on AUTO display startup elapses. As an example, AUTO 5 SEC
activates the simulated Enter press every 5 seconds. To terminate AUTO display,

press the ATTN key. When you use AUTO display, the terminal from which you
issue the command is locked, and it is unusable for any other function while
AUTO display is active.
The method by which display exception processing checks values against those
in your exception threshold data set is the same as the method for periodic
exception processing. At the precise instant that you press Enter,
instrumentation data and the values in your exception threshold data set are
compared. Therefore apply the considerations you make for periodic exception
processing intervals to the display exception intervals you adopt.
3.2 Activating the Exception Processor

Use the Exception Processor panel (see Figure 12 on page 35) to activate and
deactivate various exception processes by selecting exceptions under
Activate/Deactivate Exception Processing .
To display this panel, select option 5, Control Exception Processing, from the
DB2 PM Online Monitor Main Menu. Previously selected fields are indicated
with a greater-than symbol (>).
3.3 Exception Display Modes

A number of methods of presenting exception conditions exist. Some are
triggered automatically, whereas others require the use of commands.
3.3.1 Periodic Exception Conditions

If any periodic problem level exceptions are detected, the Exception Notification
window is displayed. The display shows date, time, and the severity of the
exception (see Figure 14 on page 39).
38 DB2 PM
95/04/24 14:29 Thread Summary ROW 1 TO 15 OF 15
Command ===> _________________________________________________________________
_
ST11DB2F DB2F V4
To display a thread, place

--------------------------------------------
P| Exception Notification | -------
Primauth Planname n | | Class 2
_ DB2RES2 DSNTEP41 D | Time . . : 95/04/24 14:28:21 |03.60278
_ DB2RES2 DB2PM410 N | |0.000069
_ DB2PMF DB2PM410 N | Periodic Exceptions |3.060885
_ DB2PMF DB2PM410 N | Problem . . . . . . . . . . . : 1 |0.050353
_ DB2PMF DB2PM410 D | Warning . . . . . . . . . . . : 0 |3.941159
_ DB2PMF N| |0.198706
_ DB2FSPA N | Exception Events | N/P
_ DB2FSPA N | Deadlock . . . . . . . . . . . : 0 | N/P
_ DB2FSPA N | Timeout . . . . . . . . . . . : 0 | N/P
_ DB2FSPA N | EDM Pool Full . . . . . . . . : 0 | N/P
_ DB2FSPA N | Authorization Failure . . . . : 0 | N/P
_ DB2FSPA N | Thread Commit Indoubt . . . . : 0 | N/P
_ DB2FSPA N | CF rebuild/alter start . . . . : 0 | N/P
_ DB2FSPA N | CF rebuild/alter end . . . . . : 0 | N/P
_ DB2FSPA N| | N/P
-- End of Thread list -- | F1=Help F12=Cancel |
---------------------------------------------
F1=Help F3=Exit F5=Auto F6=History F7=Up F8=Down

F10=Qualify F11=Sort F12=Cancel
Figure 14. Periodic Exception Notification Window
In addition to this window, a log that you access by issuing the LOOK command
is available. The log supports 500 entries, at which point the log wraps and
overwrites the oldest entry.
From the command line issue the LOOK command to get to the Look Selections
panel (Figure 15 on page 40).

Look Selections
Command ===> ________________________________________________________
_
Subsystem: ST11DB2F DB2F V4
Select one of the following displays
_1 1. Periodic Exceptions
2. Periodic Exceptions Messages
3. Display Exceptions
4. Authorization Failure Summary
5. Exception Event Summary
6. Exception Event Messages
Figure 15. Look Selections M e n u
Options 1 and 2 relate to periodic exceptions. Option 1, Periodic Exceptions,

enables you to look retrospectively at problem or warning exceptions (see
Figure 16 on page 41). If the thread is still active, by selecting the exception
event, you are taken into the Thread Detail panel related to the exception
condition. From the Thread Detail panel you can investigate the problem further.
Option 2, Periodic Exception Messages, gives information about the start time
and date of the periodic exception processor.
If the data collector is active, when selecting an event you can view the Thread
Detail panel and process the information in history format. If the data collector
is inactive, and the thread has terminated, you cannot obtain any information
from the Thread Detail panel.
40 DB2 PM
Look Selections
-----------------------------------------------------------------------------
| Periodic Exceptions List ROW 19 TO 20 OF 20 |
| Command ===> ______________________________________________________________ |
| |
| |
| Periodic Interval started . . . . . . . : 95/04/24 15:11:07.66 |
| Last Interval . . . . . . . . . . . . . : 95/04/24 15:23:48.78 |
| |
| Time Location Group Subsystem Member Corrname |
| Reqloc Primauth Planname Connect Corrnmbr |
| Field Value Compare Threshold Type By |
| Descr |
| -------- ------------------ -------- ------------ -------- ---------- |
| _ 15:13:47 ST11DB2F ¢BLANK¢ DB2F ¢BLANK¢ DB2RES2B |
| ¢BLANK¢ DB2RES2 DSNTEP41 BATCH ¢BLANK¢ |
| ADDB2ETT 185.592461 > 5 Problem Total |
| ELAPSED TIME IN DB2 (CLASS 2) |
| |
| _ 15:13:47 ST11DB2F ¢BLANK¢ DB2F ¢BLANK¢ DB2RES2B |
| ADRECETT 186.078328 > 20 Problem Total |
| ELAPSED TIME IN APPLICATION (CLASS 1) |
| |
¢-----------------------------------------------------------------------------¢
Figure 16. Periodic Exceptions List Window
3.3.2 Display Exception Conditions

When using display exception processing, fields shown on the panel displayed
are checked for exception whenever the display is refreshed with new data or
historical data. Fields found in exception are shown in reverse video, and the
color of the field shows the severity of the exception. Warning level exceptions
are highlighted in yellow, and problem level exceptions are highlighted in red.
When viewing threads from the Thread Summary panel, consider using both the
QUALIFY and SORT commands to focus on specific types of threads and report
the highest activity relating to the exception condition. For example, if your
threshold is examining the elapsed time of connections from IMS-MPP, use the
QUALIFY command to include only those threads and the SORT command to
order the highest elapsed time and exception condition to the top of the panel.
Online Monitor User ′ s Guide , Chapter 11, “Viewing Thread Activity” for details on
the QUALIFY and SORT commands.
Figure 17 on page 42 shows how information is presented when you issue the
QUALIFY and SORT commands.

95/04/27 16:44 Thread Summary SORT QUALIFY ROW 1 TO 7 OF 7
Command ===> _________________________________________________________________
_
ST11DB2F DB2F V4
To display a thread, place any character next to it, then press Enter.
Program Connection ------- Elapsed -------

Primauth Planname name ID Status Class 1 Class 2
_ SAD0RG1 TRPP012P N/P IMSA APPL 1:42.48296 0.121860
_ STSGSH JEQA61IP N/P IMSA APPL 1:14.87856 0.004180
_ SAD0RG1 TRPG012P N/P IMSA APPL 47.391831 0.077698
_ RWYTC7P RWYTC7P N/P IMSA APPL 43.395636 0.003846
_ SMOBAHX TRPG013P N/P IMSA DB2 12.758019 0.000323
_ TRPG013P J10H01P N/P IMSA DB2 0.239298 0.046248
_ HAWKINS TRPP013P N/P IMSA DB2 0.068308 0.000311
-- End of Thread list --
.-----------------------------------------------------.
| DGOM911 Display exceptions found. 5 total 4 problem |
F1=Help ¢-----------------------------------------------------¢ 6=History
F7=Up F8=Down F9=Swap F10=Qualify F11=Sort F12=Cancel
Figure 17. Thread Summary Panel Showing Exceptions
Below we describe the conditions that could cause exceptions not to be

reported. If you initialize the DB2 PM Online Monitor with only thread detail
exception processing but choose to monitor from the Thread Summary panel,
exceptions are not detected. The converse is also true.
If you specify, in your exception threshold data set, only fields that are found on
the Thread Detail panel, for example, Maximum page locks held , and choose to
monitor from the Thread Summary panel, exceptions are not reported.
Consider your requirements carefully and decide from which panel you want to
monitor your DB2 PM Online Monitor exceptions. This decision governs the
fields that are applicable. We recommend, under normal monitoring conditions,
that you use a combination of Display Thread and Periodic Statistics so that you
can see the highlighted threads and obtain statistics exceptions.
In addition to the reverse video warnings for exception conditions, you are
presented with a small window at the bottom of your Thread Summary panel
(see Figure 17). This window is presented each time the screen is refreshed
after the detection of an exception condition. The window message notes that
display exceptions have been detected and gives the total number and the
number in a problem exception state. A warning exception is not specifically
reported but contributes to the value in the total field.
Display exception events are tracked in much the same way as periodic
exception events. Display exception events are written to a display exception
log, which you can access through the LOOK command. The log contains a
maximum of 500 entries, at which point it wraps.
42 DB2 PM
3.4 Alternative Reporting Methods
Exception processing output data can be written to data sets. Use these data
sets for further analysis of exception conditions.
3.4.1 Exception Log File Data Set

You can specify an exception log file data set to which exception condition
records are written. The contents of the exception log file data set can be either
printed using the DB2 PM Exception log file print utility (the sample JCL is in
member DGOMEJCL in the SDGOSAMP library) or used as input to the LOAD
utility.
You can specify NEW, APPEND, or OVERWRITE for the data set disposition. Use
NEW if you want the data set to be dynamically allocated, APPEND if you want
the new records for exception conditions to be appended to the existing records
in the data set, and OVERWRITE if you want the new records for exception
conditions to overwrite the existing records in the data set.
See Appendix B, “DB2 PM Data Sets” on page 185 for the exception log file
data set attributes.
3.4.2 DPMOUT Data Set

You can specify a DPMOUT data set to which exception condition records are
written. The contents of the DPMOUT data set can be used as input to the DB2
PM Batch record trace or statistics trace for a more detailed analysis of
exception conditions.
You can specify NEW, APPEND, or OVERWRITE for the data set disposition. Use
NEW if you want the data set to be dynamically allocated, APPEND if you want
the new records for exception conditions to be appended to the existing records
in the data set, and OVERWRITE if you want the new records for exception
conditions to overwrite the existing records in the data set.
See Appendix B, “DB2 PM Data Sets” on page 185 for the DPMOUT data set
attributes.
Refer to IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4
Report Reference , “Appendix A” for the DPMOUT record layout.
3.4.3 FILE Subcommand

Use the FILE subcommand in DB2 PM Batch to produce a sequential data set
containing accounting, audit, locking, record trace, or statistics data. You can
choose all or only exception records for accounting and statistics. This
sequential data set can be used as input to the LOAD utility.
DB2 PM provides sample DDL to create DB2 tables and sample statements to be
used with the LOAD utility. In addition, sample DML (SQL queries) is provided to
retrieve information from those tables. You can find sample definitions in the
SDGOSAMP data set.
Report Reference for details about FILE for accounting, audit, locking, record
trace, and statistics.

3.5 Deactivating Exception Processing
You can stop exception processing by:
• Deselecting the appropriate fields from the Exception Processor panel
• Exiting from DB2 PM, with the data collector inactive
• Changing DB2 subsystems from the DB2 Subsystems List.
Online Monitor User ′ s Guide , Chapter 9, “Exception Processing” for details.
3.6 Setting Exception Thresholds

Setting exception thresholds is a crucial and important aspect of exception
processing. The Service Level Agreements are a good source of time thresholds.
The identification of the fields checked for exceptions and the warning and
problem values you specify are the focus for accurate and objective exception
processing.
If, after populating and using your exception threshold data set, you have a large
number of problem entries, the threshold values attributed to your nominated
fields are probably incorrect, or you may have a serious problem.
By definition an exception is an unusual and uncommon occurrence. Keep this

definition in mind when you develop your exception threshold data set and be
prepared to modify values.
Because the definition of entries and decisions about threshold values are such
important tasks, which can be time consuming and rather imprecise, DB2 PM
provides a starter set of suggested fields and a method of calculating values for
you. The function is called PROFILING and is discussed in detail in 3.7,
“Exception Profiling” on page 49.
3.6.1 Defining a Threshold Data Set

You can define any number of exception threshold data sets; however, only one
can be active per user address space. With increasing experience, you can
develop a number of threshold data sets that can be used for either general
exception detection or a more specific range of applications. For example, you
can populate a threshold data set that checks defined values against fields such
as class 1 elapsed time, number of getpages, and other read I/O for a
business-critical set of plans, whereas you can use a different threshold data set
overnight to monitor the batch environment.
Having stated the above, we would like to point out that you can define different
exceptions for different applications (actually, plans) in one exception threshold
data set. Thus you do not have to “switch” exception threshold data sets when
you may have a mixed workload.
Generally, you would have two distinct types of exception threshold data sets.
You would use one exception threshold data set as part of your periodic
monitoring cycle as input to your accounting or statistics exception reports. This
exception threshold data set is likely to evolve over a period of time. You would
use the other exception threshold data set when specific DB2 problems arise, by
44 DB2 PM
defining thresholds related to the perceived problem, and its life may extend
only until the problem is resolved.
See Appendix B, “DB2 PM Data Sets” on page 185 for information about
allocating a new exception threshold data set.
3.6.2 Defining Threshold Data Set Entries

You populate your threshold data set by using a series of panels that guide you
through the process. The panel options relate to either accounting events or
statistics events. The accounting fields and statistics fields to be checked for
exception can be combined to form an exception threshold data set or kept
separately as desired.
Note:
The By field in the Exception Threshold Field Details panel requires

explanation (see Figure 20 on page 52). Both the By Total and By Thread
options produce different results when used with the accounting report
set. Where accounting report fields are preceded by #, the values
associated with those fields are total values; for example, #OCCURS
reports the total number of occurrences of a thread. The other fields
show average values based on the number of occurrences.
If you define your thresholds based on fields showing total values, choose
the By Total instead of By Thread option. If you define your thresholds
based on fields showing average values, choose the By Thread instead of
By Total option.
Consider four threads, each taking 10, 15, 5, and 8 seconds of class 1
elapsed time, respectively. Your exception threshold is set to trigger at
> 10 seconds for class 1 elapsed time. Using the By Total option in
conjunction with an accounting report produces the following result: The
four occurrences of elapsed time are added together, totaling 38 seconds,
and that value is compared to the threshold value of 10 seconds. An
exception condition is reported.
Using the By Thread option in conjunction with an accounting report

produces the following result: The four occurrences of elapsed time are
added together, totaling 38 seconds, and then divided by the number of
occurrences, resulting in a value of 9.5 seconds. That value is then
compared to the threshold value of 10 seconds. An exception condition is
not reported.
Online Monitor User ′ s Guide , Chapter 9, “Exception Processing ” for details
about how to define exception threshold values.
3.6.3 Fields for Populating the Threshold Data Set

You will find the fields we recommend in this section useful. They are intended
as a starter set geared to track some fundamental elements of performance
within a DB2 subsystem. The organization of this section reflects two distinct job
responsibilities, the system programmer and the database administrator.
Appendix C, “Significant Exception Reporting Fields” on page 187 contains a

more comprehensive list of fields and recommended actions for resolving
exception conditions.
The initial threshold values in your exception threshold data set may generate a
high number of exceptions, and you should adjust them to report only genuine
exceptions. For example, if, in your DB2 system, applications legitimately
generate deadlocks, consider setting your threshold for deadlock exceptions
above the acceptable value. Over a period of time and as an ongoing process
your exception threshold data set should evolve to reflect accurate values.
3.6.3.1 The System Programmer

The system programmer is primarily concerned with performance issues that
affect the DB2 subsystem as a whole and therefore is likely to base
measurements against DB2 PM statistics information.
Table 2 shows the exception reporting fields that are of interest to the system
programmer.
Table 2 (Page 1 of 2). Exception Reporting Fields for the System Programmer
Field ID Field Name Compare Suggested
Operator Value
QISEFAIL EDM pool full > 0
QBSTDMC Data Manager critical threshold > 0
QBSTXFL Buffer pool full > 0
QBSTXPL Virtual storage unavailable > 0
QBSTSPD Prefetch disabled/no buffer > 0
QBSTJIS Prefetch I/O streams reduced > 0
QBSTPL2 Prefetch I/O streams reduced to > 0

1/4
QBSTRTO DFHSM recall timeouts > 0
QBSTWKPD Prefetch not scheduled-zero qty > 0
QBSTRPI Number of page-ins required for > V

read I/O
QBSTWPI Number of page-ins required for > V
write I/O
QBSTWFF Inefficient merge pass/buffer pool > 0
shortage
QBSTWFD Work files rejected-buffer pool > 0
shortage
QBSTMAX Work file not created during > 0
sort-buffer pool shortage
QBSTHRF Requested page found in the > V
hiperpool-content discarded by
MVS
46 DB2 PM
Table 2 (Page 2 of 2). Exception Reporting Fields for the System Programmer
Operator Value
QBSTHWF Synch or asynch write request > V
failed-shortage of expanded
storage
SRTTERM RID list processing failure for any > 0
reason
QDSTQDBT DBATs queued-maximum active > 0
Q3STCTHW Number of threads queued at > 0

create
QTXADEA Number of deadlocks > V
QTXALES Lock escalation share > 0
QTXALEX Lock escalation exclusive > 0
QJSTRARH Log reads from archive log > 0
QJSTWTB Output log buffers unavailable > 0
You can at your discretion replace 0 in the Suggested Value field with a small
value.
A V in the Suggested Value field indicates that the actual value is installation or
plan specific. To determine what V should be, consider using the DB2 PM
PROFILING mechanism.
3.6.3.2 The Database Administrator

The database administrator′s workload tends to be high, so the minimum
amount of quality information must be presented with the maximum benefit. The
database administrator′s most crucial use of DB2 PM Online Monitor exception
monitoring usually maps the enterprise′s online window. Problems generating
the greatest focus probably are related to transactions that have the highest
expected throughput or are business critical.
Both types of transactions are common because their success or failure is

measured by their elapsed time. It may be possible for you to base your
exception processing solely on the expected elapsed time of your critical
transactions. First identify up to five transactions by mapping them to the plans
they execute. Either refer to the Service Level Agreement to certify the expected
response time or, to get a general idea of how closely the transactions are
performing to their expected goal, consider using the DB2 PM PROFILING
mechanism.
For each identified plan, map an elapsed time that triggers a warning exception
and an elapsed time that triggers a problem exception. Your threshold data set
could therefore consist of five entries with specific elapsed time thresholds for
each plan. The triggering of an exception indicates that one of your critical
transactions is not performing; further investigation is warranted.
Be aware, however, that for IMS-WFI transactions and CICS transactions using
protected threads, the same thread can be reused by multiple transactions.

Should there be a delay in the arrival of the next transaction, the thread is
terminated. Accounting data is written only when the thread is either terminated
or reused, provided that TOKENI is specified as YES in the TYPE=INIT macro
and/or TOKENE is specified as YES in the TYPE=ENTRY macro in the CICS
resource control table (RCT). Therefore in this situation where there is delay in
the arrival of the next transaction, the class 1 elapsed time can give a false
impression of a problem as it may reflect the delay until the next signon,
resignon, or thread termination.
Although DB2 PM exception processing is primarily used as a problem

determination tool, it can prove effective as a mechanism for capacity planning.
By understanding the profile of your DB2 system in terms of workload values,
such as expected number of getpages per day, SQL DML executed, EDM pool
usage, and logging activity, you can develop exception thresholds. Through
exception reporting you can identify trends or peak activities that may lead you
to examine your system capacity and make provision for future actions before
problems arise.
Table 3 shows the exception reporting fields that are of interest to the database
administrator.
Table 3 (Page 1 of 2). Exception Reporting Fields for the Database Administrator
Operator Value
ADRECETT Class 1 elapsed time > V
QXINCRB Number of incremental binds > 0
QWACAWAR Time waiting for archive reads > 0

from tape
ADTSUSC Total number of class 3 > V
suspensions
QXPREP Number of prepare statements > V
executed
ASRIUDCA Update/Delete/Insert per commit > V
ARTTERM RID list processing failure for any > 0

reason
ADTOTPFL Parallel groups falling back to > 0
sequential mode
QXREDGRP Parallel groups running in a > 0
reduced degree
QTXATIM Lock timeout count > 0
QTXADEA Deadlock count > 0
QTXALES Lock escalations share > 0
QTXALEX Lock escalations exclusive > 0
QBACIMW Number of immediate writes > V
ADRGPRIO Number getpages per read I/O < V
48 DB2 PM
Table 3 (Page 2 of 2). Exception Reporting Fields for the Database Administrator
Operator Value
QLACCNVQ Conversations queued by DDF > V
You can at your discretion replace 0 in the Suggested Value field with a small
value.
A V in the Suggested Value field indicates that the actual value is installation or
plan specific. To determine what V should be, consider using the DB2 PM
PROFILING mechanism.
3.7 Exception Profiling

Most DB2 professionals recognize events that lead to critical DB2 subsystem
situations, for example, data manager threshold reached. Therefore it is initially
quite straightforward to identify the fields and values that make up the exception
threshold data set. However these fields and values tend to be directed toward
general DB2 subsystem performance matters. Deciding on exception values for
specific plans, connection types, or correlation IDs, for example, is a much more
complex task.
To help overcome this problem DB2 PM Exception Profiling calculates an

exception threshold value based on a range of data provided and the percentage
of those records that you want to trigger exceptions.
3.7.1 How Profiling Works

The result of a profiling operation is a derived value for a particular field that you
use to populate your exception threshold data set. The process is:
1. Identify candidate fields.
2. Choose the percentage of records in each field that triggers exceptions.
3. Identify input data.
4. Choose to populate both the profile report and threshold data set from the
Exception Profiling panel.
5. Execute exception profiling.
6. Examine the profile report and either accept or modify the recommended
values.
3.7.2 Input Data Used for Profiling

You can use GTF, SMF or DPMOUT data as the input for exception profiling. The
input data should contain a sufficient number of records and span an appropriate
time period to make the calculation a representative profile. Each DB2 PM
instrumentation record is processed from the input data set, and the value from
the field identified for exception profiling is recorded. When all records have
been processed, statistics are generated to determine the threshold value.
During exception profiling, some lengthy processing may result if you use large
amounts of SMF or GTF data, especially when multiple fields are being
calculated in one execution.

If you can identify a representative cross section of data, it may be beneficial to
use a DPMOUT data set as input to exception profiling, especially if repeat
iterations are required. Significant savings in terms of I/O and elapsed time can
be expected. If you use a DPMOUT data set, remember that exception
thresholds report both accounting and statistics exceptions, so your DPMOUT
data set should contain the appropriate records.
Selecting option 6, Exception Profiling, from the DB2 Performance Monitor panel
displays the panel shown in Figure 18. Use this panel to specify your warning
and exception percentage values and nominate the input and output data sets.
Press Enter to generate the JCL. Execute this JCL to produce the calculated
exception thresholds.
DGOFEP00 Exception Profiling

Command ===> ____________________________________________________________
Complete the following control information, then press Enter.
Warning exceptions . . . . . . . . . . . 5____ (% of input data)

Problem exceptions . . . . . . . . . . . 1____ (% of input data)
Produce profile report . . . . . . . . . 1 (1=yes 2=no)
Input data set

¢STSGMG.DPMOUT¢_______________________________
Input threshold data set

¢STSGMG.DB2PMV4.THRESH1¢______________________
Output threshold data set

¢STSGMG.DB2PMV4.OUT1¢_________________________
Output report data set

¢STSGMG.DB2PMV4.REP1¢_________________________
Figure 18. Exception Profiling Panel
The Exception Profiling panel shows the required data sets. The input threshold
data set can be either the data set provided with DB2 PM, which you can copy
and tailor, or the data set you populate yourself. The sample threshold
members (DGOETV30 for DB2 V3 and DGOETV41 for DB2 V4) are provided in
SDGODATA. The output threshold data set contains the result of the profile
generation and is therefore to be regarded as input to exception processing.
Plan to produce an exception profiling report. This report is for your use only
but provides useful information on the calculated values (SPECIFIED
THRESHOLD), and the expected number of exceptions (EXCEPTIONS
GENERATED) for various exception percentages. Figure 19 on page 51 shows
an example of the output report.
50 DB2 PM
ACTUAL AT: 04/18/95 18:33:47.08 DB2 PERFORMANCE MONITOR (V4) PAGE: 1
INPUT FROM: 04/16/95 22:20:05.13 EXCEPTION PROFILING REPORT
INPUT TO: 04/17/95 22:04:57.68
WARNING THRESHOLD % 5.00

PROBLEM THRESHOLD % 1.00
FIELD ID LOCATION PLAN CONNECT EVENT PER OPERATOR OCCURRENCES DESCRIPTION
FIELD QUALIFIER
--------------- ------------------ -------- -------- ----- ------ -------- ----------- -------------------------------------
ADRECETT * RGERR1P * ACCT VALUE > 18271 CLASS 1 ELAPSED TIME
N/P
------------------------------------------------------------------------------------------------------------------------------------
| | PROBLEM | WARNING | 0.10 % | 0.25 % | 0.50 % | 1.00 % | 1.50 % | 2.00 % |
------------------------------------------------------------------------------------------------------------------------------------
| SPECIFIED THRESHOLD | 0.165513 | 0.045480 | 0.661383 | 0.444442 | 0.299332 | 0.165513 | 0.114954 | 0.091715 |
------------------------------------------------------------------------------------------------------------------------------------
| EXCEPTIONS GENERATED | 20 | 100 | 2 | 5 | 10 | 20 | 30 | 40 |
------------------------------------------------------------------------------------------------------------------------------------
ADDBTCBT * RGERR1P * ACCT VALUE > 18271 CLASS 2 TCB TIME
N/P
------------------------------------------------------------------------------------------------------------------------------------
| | PROBLEM | WARNING | 0.10 % | 0.25 % | 0.50 % | 1.00 % | 1.50 % | 2.00 % |
------------------------------------------------------------------------------------------------------------------------------------
| SPECIFIED THRESHOLD | 0.016258 | 0.004297 | 0.032145 | 0.029020 | 0.022646 | 0.016258 | 0.014954 | 0.012324 |
------------------------------------------------------------------------------------------------------------------------------------
| EXCEPTIONS GENERATED | 20 | 100 | 2 | 5 | 10 | 20 | 30 | 40 |
------------------------------------------------------------------------------------------------------------------------------------
EXCEPTION PROFILING REPORT COMPLETE
Figure 19. Exception Profiling Report
The report not only gives the recommended problem and warning threshold
values but also provides values above and below the recommended value so
that you can make adjustments without rerunning the profiling function. These
alternate values are percentages in multiples of 0.1, 0.25, 0.5, 1.0, 1.5, and 2
times the problem exception percentage specified on the Exception Profiling
panel.
See Figure 20 on page 52 for a sample input specification for the exception
threshold data set used in exception profiling. When specifying values for the
exception threshold data set in the Exception Threshold Field Details panel
shown in Figure 20 on page 52, ensure that you specify an asterisk (*) in either
the warning threshold field or problem threshold field or both as required. This
specification is important as only fields found with an asterisk are replaced with
calculated values during exception profiling.
You can specify additional criteria for qualifying the data that you want checked
during exception processing for an exception threshold entry. These criteria are
useful when you want to specify different exception threshold values. For
example, you may want to specify different elapsed time thresholds for online
transactions and batch jobs. You can achieve this by having two entries with
different threshold values, and each entry qualified by the appropriate
connection ID.

Exception Threshold Field Details
Command ===> ____________________________________________________________
Update fields as required, then Exit to save.
ENTRY 1 OF1
Category . . . . . : Elapsed, CPU and Waiting Times per Plan Execution

Field ID . . . . . : ADDB2ETT
Description . . . . : Elapsed time in DB2 (Class 2)
Active . . . . . . . . . . . . . 1 1=Yes 2=No
By . . . . . . . . . . . . . . . 1 1=Total 2=Minute 3=Second

4=Commit 5=Thread
Compare operator . . . . . . . . > <=Less than >=Greater than

Warning threshold . . . . . . . . * __________
Problem threshold . . . . . . . . *___________
Local location . . . . . . . . . __________________

Group name . . . . . . . . . . . ________
Member name . . . . . . . . . . . ________
Subsystem ID . . . . . . . . . . ____
Requester location . . . . . . . __________________
Connect . . . . . . . . . . . . . ________
Planname . . . . . . . . . . . . RGERR1P
Corrname . . . . . . . . . . . . ________
Corrnmbr . . . . . . . . . . . . ________
Primauth . . . . . . . . . . . . ________
F1=Help F3=Exit F5=Add F6=Delete F7=Up F8=Down
F10=Previous F11=Next F12=Cancel
Figure 20. Exception Threshold Field Details Panel
3.8 Data Collector and History Function

The DB2 PM data collector stores instrumentation data, collected over a period
of time, and makes this data available to the DB2 PM Online Monitor when the
history function is used. The obvious benefit of the data collector is that, in
conjunction with the history function, it enables replay of recent past events. For
example, using the DB2 PM Online Monitor, you may want to view the events
occurring immediately before an exception threshold is reached.
3.8.1 Collecting Data

To view recently completed events, the data collector must be active so that
instrumentation data can be gathered.
Your installation can choose to collect data at the following levels:

• Thread summary
• Thread detail
• Thread detail with locking information
• Thread detail with SQL statement
52 DB2 PM
• Thread detail with locking information and SQL statement
• Statistics
• System parameters.
The data collector runs as a started task address space and is activated by the S
procname,parms command, where procname is the name of the JCL member in
the system PROCLIB concatenation, and parms are the substitution parameters
for the JCL.
The data collector stores instrumentation data in either a data space or a VSAM
data set. A data space is defined as a part of virtual storage, and you determine
the size allocated to this virtual storage. We recommend using a VSAM data set
as the target for the data captured by the data collector as there is no
perceivable degradation in performance when using the history function, and
therefore no explicit reason to use a data space. With a VSAM data set you also
have more scope in allocating a larger area for data collection than would be
viable if you used virtual storage with a data space.
Once the allocated space in either the data space or VSAM data set is
exhausted, the space wraps and the new data is written over the oldest recorded
data. An easy way to find out how far back your history data spans is to provide
in the Thread Summary or Thread Detail panel an unrealistic past date value in
the format YY/MM/DD, for example, 53/10/29. This value automatically takes you
to the earliest displayable history data and reports the date and time in the top
right-hand corner of the screen.
The time span availability of your history capability is dependent on:

• The data collector data space or VSAM data set size
• The qualification of the data being collected
• The workload within the DB2 subsystem
• The history collection interval.
Refer to the Program Directory. , Chapter 7, “Customization Instructions” for a

rough calculation of the data set size.
3.8.2 Amount of Data to Collect

Determining how much data to collect is difficult. By aggressively qualifying the
data to be considered for collection, for example, by specific plan name,
primauth, connection ID or correlation ID, you immediately restrict the scope of
your history function, reduce the amount of data collected, and therefore extend
the time span of history data availability. However, if you do not provide
qualification, you can use the history function to examine any problem in the
recent past. This approach may severely reduce the time span of data available,
however.
The data collector initialization parameters are used at invocation of the data
collector, and one of the many parameters, HISTORYINTERVAL, specifies how
often, in seconds, the data is gathered. The value can range from 0 (no data
collection) to 86400 seconds (one day). The more aggressive your collection
cycle becomes, for example, 5 seconds, the quicker the collection space wraps.
The HISTORYINTERVAL also determines the history playback interval.

Because the data collector gathers information at intervals, the replay of the
information occurs at the interval at which it was collected. The playback is not
continuous but jumps between interval periods. For example, if the
HISTORYINTERVAL is set to 10 seconds, then, when you use the history function,
every time you press Enter the displayed data moves forward by 10 seconds. It
is important therefore to consider the type of thread information required for
history collection, because this information influences the setting of the
HISTORYINTERVAL parameter.
You can dynamically change data collector parameters, provided you have the
required authorization, by accessing the Data Collector Parameter panel.
Changes made through that panel remain in effect until you stop the data
collector.
Online Monitor User ′ s Guide , Chapter 20, “Administrator User,” for details on the
authorization required.
3.8.3 Collection Dependencies

DB2 PM functions that rely on the data collector are:
• The DIAGNOSE command, which requires history to be active in the data
collector
• Periodic exception processing while the user is not logged on to the TSO
system
• Exception event processing.
3.8.4 Using the History Function

The history function lets you recall and view thread activity, statistics, and
system parameters previously collected by the data collector. It is particularly
useful in situations where exception conditions have been raised and you want
to replay the activities occurring at either a system level or thread level.
Depending on the level of data you have collected (see 3.8.1, “Collecting Data”
on page 52), you can process information from many of the DB2 PM Online
Monitor panels. The word HISTORY and the past date is displayed at the top of
the panel when you invoke the history function. Particularly useful, when
replaying the history information, is the ability to view:
• Locking information displayed from the Locked Resources option of the
Thread Detail panel
• SQL statements executing from the SQL Statement and Package option of
the Thread Detail panel
• Access path information from the DB2 PM explain function. It is certainly
useful to view access path information from the history function. However,
be aware that history does not store access path information. The access
path that you see is the access path of a current dynamic explain or from the
current plan table, not necessarily the access path that was used at the time
the history information was collected.
You also can use the DIAGNOSE command to identify exceptional conditions and
recommendations for resolution. For further information and a description of the
history commands Refer to the IBM DATABASE 2 Performance Monitor for MVS
(DB2 PM) Version 4 Online Monitor User ′ s Guide , Chapter 8,“Viewing Past Data.”
54 DB2 PM
3.9 Problem Determination
The DB2 PM Online Monitor diagnose function simplifies problem determination.
It analyzes a thread′s performance data, presents an online diagnosis of the
principal factors contributing to the thread′s performance degradation, and
provides recommendations for problem resolution.
The DB2 PM Online Monitor Diagnosis of Thread window also simplifies problem
determination by listing all of the constraints detected by the diagnose function.
3.9.1 The Diagnose Function

The diagnose function analyzes the performance data for the selected thread
and compares it to the Diagnosis rules of thumb stored within DB2 PM. These
rules of thumb , when used in conjunction with one another, determine the
constraints or inhibitors acting on a thread. Of the many rules of thumb that the
diagnose function uses, Figure 21 identifies 12 with the default values that you
can change.
Diagnosis Rules of Thumb
Update fields as required, then Enter.
Rule of Thumb Current Suggest Maximum
High synchronous I/O suspension (msec) . . . . 25___ 25 10000

High other read I/O suspension (msec) . . . . 4____ 4 10000
High lock suspension (msec) . . . . . . . . . 1000_ 1000 10000
Low system share (%) . . . . . . . . . . . . . 1.00_ 1.00 99.99
Low buffer pool read hit ratio (%) . . . . . . 50___ 33 100
Low prefetch utilization (%) . . . . . . . . . 90___ 90 100
High commit rate (%) . . . . . . . . . . . . . 10___ 10 100
High synchronous write rate (%) . . . . . . . 1____ 1 100
High lock suspensions per request (%) . . . . 10___ 10 100
High drain and claim suspension (%) . . . . . 20___ 20 100
High hiperpool write failure rate (%) . . . . 10___ 10 100
High hiperpool read failure rate (%) . . . . . 10___ 10 100
Figure 21. Sample Diagnosis Rules of Thumb Panel
For example, the high synchronous I/O suspension for a thread has a default
value of 25 milliseconds. If, in its analysis, the diagnose function detects that the
thread′s average synchronous I/O suspension exceeds the default value, it
considers that there is a constraint on the thread′s performance and identifies
synchronous I/O suspension as a possible contributor to the problem.
You can change the default values for any of the 12 diagnosis rules of thumb
listed in Figure 21 to those values that best reflect the needs of your
environment. To change the defaults, run the DB2 PM REXX EXEC, DGOJVARS,
and select the Adjust diagnosis rules of thumb option. The DGOJVARS REXX
EXEC is in the DB2 PM target library, SDGOSAMP. Refer to the IBM DATABASE
2 Performance Monitor for MVS (DB2 PM) Version 4 Online Monitor User ′ s Guide ,
Chapter 17, “Customizing Thread Diagnosis.”

Thread diagnosis requires that monitor trace classes 1, 2, and 3 have been
started. Additional diagnostic information is available from class 7 and class 8
data.
3.9.2 Invoking Diagnose Function

You can invoke the diagnose function from the DB2 PM Online Monitor Thread
Detail panel or any dependent panel by issuing the DIAGNOSE command or
pressing PF21. The Diagnosis of Thread window is displayed.
The Diagnosis of Thread window lists all constraints that were detected during
the diagnostic analysis, together with a current high level overview of the
thread′s time distribution. The constraints are listed in the order in which they
were detected by the diagnostic analysis; the first constraint listed is the
dominant constraint.
95/04/24 19:26 Thread Detail ST11DB2F DB2F V4

-----------------------------------------------------------------------------.
| 95/04/24 19:27 Diagnosis of Parallel Processes |
-----------------------------------------------------------------------------.
| 95/04/24 19:27 Diagnosis of Thread DB2RES2 DSNTEP41 DSNTEP2 |
| Command ===> _____________________________________________________________ |
| |
| HISTORY 95/04/24 14:03:33 |
| |
| _ The buffer pool read hit ratio for BP0 is low |
| _ The thread has experienced lock escalations |
| |
| Distribution of DB2 elapsed time (%): |
| _ Synchronous I/O . . . . . . . . . . . . . . . . . . . . . : 57.32 |
| _ Actively processing . . . . . . . . . . . . . . . . . . . : 39.37 |
| _ Waiting for system resources . . . . . . . . . . . . . . : 1.58 |
| _ Services . . . . . . . . . . . . . . . . . . . . . . . . : 0.84 |
| _ Locks and latches . . . . . . . . . . . . . . . . . . . . : 0.80 |
| |
| DB2 elapsed time in the current DBRM or package (%) . . . . . : 100.00 |
| Thread elapsed time inside DB2 (%) . . . . . . . . . . . . . : 100.00 |
| Thread active processing inside DB2 (%) . . . . . . . . . . . : 100.00 |
| |
| |
| |
¢-----------------------------------------------------------------------------¢
Data Sharing Locking Activity
Suspensions . . . . . . . . . . . . . . . : N/P
Group Buffer Pools Activity
_ Stored Procedures
F12=Cancel
Figure 22. Diagnosis of Thread Window: Diagnose Function
In the sample Diagnosis of Thread window in Figure 22, two constraints have
been detected. The buffer pool read hit ratio for BP0 is low, and the thread has
experienced lock escalations. The elapsed times for the five processing states
are shown.
56 DB2 PM
Each constraint and each processing state listed can in turn be selected for
constraint processing on constraint information panels (see Figure 23 on
page 57). A constraint information panel shows:
• The performance variables that describe the constraint
• Likely causes of the condition and the actions that may be considered for
resolution
• DB2 trace data relevant to the constraint
• Supporting information from the DB2 catalog, for example, the BIND option
• Any diagnosis rule of thumb that was influenced in detecting the constraint
• References to other related constraints, in which case you can select the
Related Constraint Information panel.
Help panels provide additional background information about the constraints.
The diagnose function not only uses the rule of thumb values but also considers
environmental conditions. For example, information on hiperpools would not be
included on the Diagnose of Thread window if the installation is not enabling the
use of hiperpools.

-----------------------------------------------------------------------------
-----------------------------------------------------------------------------|
| .--------------------------------------------------------------------------|
| | Read Hit Ratio - BP0 DB2RES2 DSNTEP41 DSNTEP2 |
| | Command ===> __________________________________________________________ |
| | |
| | HISTORY 95/04/24 14:03:33 |
| | More: + |
| | Buffer pool read hit ratio for BP0 (%) . . . . . . . . . . : 20.0 |
| | |
| | The most likely cause of a low buffer pool read hit ratio is that the |
| | buffer pool is too small. |
| | |
| | No hiperpool buffers have been allocated. You may exploit the |
| | hiperpool capability of DB2 to extend a buffer pool using expanded |
| | storage. |
| | |
| | Getpage requests . . . . . . . . . . . . . . . . . . . . . : 13914 |
| | Asynchronous pages read . . . . . . . . . . . . . . . . . : 13949 |
| | Synchronous pages read . . . . . . . . . . . . . . . . . . : 2 |
| | |
| | As a rule of thumb, the ratio is considered low when it falls below |
| | 33%. However, it may validly take high values (over 70%) for highly |
¢- | reusable data, or it may fall as low as zero and not cause concern |
¢--------------------------------------------------------------------------¢
_ Stored Procedures
F12=Cancel
Figure 23. Constraint Information Panel

3.10 Explain
The DB2 PM explain function lets you analyze the access path methods chosen
by DB2 for a single SQL statement.
There are three different methods of using the DB2 PM explain function:
• Batch explain
Batch explain can explain ALL SQL statements in a plan or package.
• DB2 PM Online Monitor explain
DB2 PM Online Monitor explain is statement-oriented. You can explain only
one SQL statement at a point in time.
• Source explain
Source explain can explain all SQL statements in the block of source
statements specified.
3.10.1 Batch Explain

To access batch explain select option 1, Create and execute DB2 PM commands
from the IBM Database 2 Performance Monitor panel. The Interactive Report
Selections panel is displayed. The Additional Functions section on the
Interactive Report Selections panel shows the Explain entry. Through the IRF,
DB2 PM builds the necessary JCL required to run explain in batch.
The explain reports can be based on the SQL statements found in:
• An application plan
• An application package
• A stored QMF query
• A specific SQL statement
• A specific query number.
When explaining statements of a package or plan, the explain execution time can
be relatively long if the plan or package holds many explainable SQL statements.
To reduce the execution time and get the required information quickly, choose
the appropriate value for the LEVEL option:
• EXPLAIN.....LEVEL(SUMMARY) shows access path information for each SQL
statement in one line for each plan.
• EXPLAIN.....LEVEL(BASIC) shows access path and explain information but
excludes information about indexes, tables, and table spaces.
• EXPLAIN.....LEVEL(DETAIL) INDEX(NO) shows all access path and explain
information. It includes information about tables and table spaces but
excludes information about indexes.
• EXPLAIN.....LEVEL(KEYDIST) INDEX(ALL) shows all access path and explain
information. It includes information about tables and table spaces as well as
all available catalog information, including key distribution and information
for all indexes created on the table.
The performance of DB2 PM batch explain execution depends on the functions

and the processing options specified because the DB2 system catalog is directly
58 DB2 PM
accessed for information. Some of the DB2 system catalog tables do not have
indexes, and therefore the catalog can play a major role in execution times.
Methods of improving the performance of explain with DB2 catalog tables that do
not have indexes are discussed in 3.10.2.1, “Performance Considerations.”
3.10.2 DB2 PM Online Monitor Explain

The DB2 PM Online Monitor explain function provides a real-time analysis of the
DB2 access path. To view the explain options, select option 10, Explain, from the
DB2 PM Online Monitor Main Menu. The DB2 PM Online Monitor explain function
is very useful for single SQL statements. You can also execute the explain
function from the SQL statement and package or DBRM option of the Thread
Detail panel.
3.10.2.1 Performance Considerations

The DB2 PM Online Monitor explain function executes in the foreground. It
explains a single SQL statement at a time, when you attempt to explain, for
example, a plan or package with many SQL statements. However, locking may
occur when selecting the plan or package containing the SQL statements.
Explain checks many values from the DB2 system catalog. Some of the DB2
system catalog tables that explain accesses do not have indexes, and thus
execution can be protracted. Explain uses the following tables that do not have
indexes:
• SYSIBM.SYSSTMT
• SYSIBM.SYSDBRM.
To improve the performance of explain, you can copy these tables and add your
own indexes. Remember, however, that DB2 does not maintain the currency of
the information in the copy tables. DB2 V4 lets you create user-defined indexes
on the DB2 catalog tables.
We recommend that you create the following:

• Two indexes for SYSIBM.SYSSTMT: one on the PLCREATOR, PLNAME,
NAME, and STMTNO columns and one on the PLNAME, SEQNO, STMTNO,
and SECTNO columns
• One index for SYSIBM.SYSDBRM on the PLCREATOR, PLNAME, and NAME
columns.
Be aware of the possible performance overhead associated with indexes and in

environments with frequent DDL and static bind activity.
3.10.2.2 Unqualified Tables

The Explain function can explain plans or packages containing SQL statements
that refer to unqualified tables, by prefixing the Current SQLID to the table name.
3.10.3 Source Explain

Source explain lets you use the explain function from the ISPF/PDF editor to
show the access path of either a single SQL statement or block of SQL
statements. Thus you can dynamically explain your SQL statements from within
the application code. The benefits are clear. You save time in not having to
jump in and out of application code to explain access paths, and you know how
closely the SQL that you are writing adheres to the application specification.

However, be aware that the credibility of the access path information depends on
the similarity between the development and production environments. The
explain function does provide a facility to accurately reflect the access path
selection expected on the production system. Through a DDF connection to the
production system you can run explain against the production DB2 tables from
your application development system. This method of using explain removes the
requirement to “fudge” the DB2 system catalog in the development environment
to enable more realistic production type access path selection.
A cautionary note, however. Remote source explain presupposes that all of the
physical database components already exist on the production system along with
all of the expected data. Thus consider remote source explain only for existing
applications on the production system that are perhaps being enhanced or for
new applications that use the existing production database environment.
3.10.4 Explain Information

You will find the following examples of explain information useful in determining
why an application does not achieve the expected performance:
• Access path chosen
Table space scans and nonmatching index scans should be avoided unless
you intend to access all rows in a given table. If the table has one or more
indexes, try to reconstruct the SQL statement in such a way that DB2
chooses a better access path. If there is no index, consider creating one.
• Index-only access
When selecting a few column values only, consider the possibility of
including these few columns in the column list of the indexes. In this way, all
requested data can be found in the index. If you are selecting a maximum
value, you might consider building a descending index on that column (or
ascending index if the minimum value is required). In this way you can even
avoid scanning leaf pages in the index structure.
• Clustering or clustered index
If DB2 has chosen a clustering index, ensure that the index is actually
clustered. If the DB2 PM Online Monitor explain function shows the
clustered value NO, or the cluster ratio is less than 85%, the table space
might need to be reorganized to bring the data rows into clustering
sequence.
• Number of matching columns
If the DB2 PM Online Monitor explain function shows that DB2 has selected a
matching index scan for the access path, verify that the number of columns
used in the index is what you expect.
• Active pages or pages with rows
Check that the number of pages with rows is about the same as active pages
especially if you are performing table space scans. In other words, the value
shown in the Percentage of pages used field by the DB2 PM Online Monitor
explain function should be as close as possible to 100%.
• Number of tables per table space
Select the Table field on the Explain Output panel. If the table space
containing this table has data only for this table, the Table Information
window is displayed. However, if the table space containing this table has
60 DB2 PM
data also for other tables, the Table Space Information window is displayed.
The Tables field on the Table Space Information window shows the number
of tables located in the table space. If the access path is table space scan
and the table space is not segmented, we recommend that there be only one
table per table space. If the table space is not segmented and the table
space contains data for more than one table, all tables are scanned, even if
you are selecting data from only one table.
• Host variable definition or column definitions
An inconsistency between the host variable definition and the corresponding
column definition shown on DB2 Explain Output panel could indicate an
inefficient access path selection, resulting from a possible disqualification of
index use.
For more information about Batch explain and DB2 PM Online Monitor explain
refer to the IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4
Batch User ′ s Guide , Chapter 15, “Monitoring the Access Path - Explain” and the
IBM DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4 Online
Monitor User ′ s Guide , Chapter 13, “Monitoring the Access Path - Explain.”
3.11 Problem Resolution Using DB2 PM Online Monitor Exceptions

Figure 24 on page 62 shows a sample sequence of actions that you can take to
resolve a problem using the DB2 PM Online Monitor and its associated
functions. Before adopting this approach consider its suitability for your
environment.

---------------
| |
| Exception |
| Reported |
| |
---------------
|
|
---------------
| View |
| Periodic |
| Exception |
| Log |
---------------
|
|
---------------
| Subsystem |
| or |
| Application |
| Problem |
---------------
|
|
---------------
Y | Data | N
-----------------| Collector |---------------
| | Active? | |
| --------------- |
| |
| |
--------------- -----------------
| Thread and | | Problem |
| Statistics | Y | Occurring or | N
| History | ----------| Recreatable |------------------
| Data | | | DIAGNOSE | |
--------------- | ----------------- |
| | |
| | |
--------------- --------------- ---------------
| | | Configure | | Switch SMF | N
| DIAGNOSE | | Collect | | or Process |---------
| | | Task | | Active SMF | |
--------------- --------------- --------------- |
| | | |
| | | |
| | Y | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| --------------- | ---------------
| | Accounting | | | Set Up |
| | and |<---------------------------------------------| Exception |
| | Statistics | | Triggers |
| | Reports | |Collect Data |
| --------------- ---------------
| |
| |
| ---------------
| | |
| | Detailed |
---------------------->| Reports |
| |
---------------
Figure 24. Road Map for Problem Resolution: DB2 PM Online Monitor Exceptions
62 DB2 PM
3.11.1 Exception Reported
In the DB2 PM Online Monitor environment, problem detection should start with
a notification of an exception event. Exception monitoring does not necessarily
require DB2 personnel to view a DB2 PM display or be within the DB2 PM task.
Indeed exception monitoring is a passive task. The exception condition raised is
most likely to be reported as a TSO message from DB2 PM indicating that a
periodic exception has occurred. In the event that you had logged off TSO, the
messages are reported when you log on to the system.
3.11.2 View Periodic Exception Log

Identify the exception condition by using the LOOK command from within the
DB2 PM Online Monitor. LOOK displays the LOOK selections menu, or you can
type LOOK 1 and press Enter from any DB2 PM Online Monitor command line.
The periodic exception log displays the most recent periodic exceptions. In
making a selection against the thread causing the exception, if the thread is still
active, the Thread Detail Panel or Statistics Panel is displayed. If the thread has
terminated but the data collector was active at the time of the exception, past
data is automatically retrieved and the exception fields are displayed. See
Figure 16 on page 41 for an example of the Periodic Exception List window.
3.11.3 Subsystem or Application Problem

From the notification of the exception events, you should be able to determine
whether the exception conditions relate to the subsystem or to the applications.
3.11.4 Data Collector Active?

The course of problem determination is now determined by the availability of the
appropriate information. The problem determination primarily revolves around
the use of the data collector in providing history information. The data collector
should always be started so that recent past events are available through the
HISTORY function.
3.11.5 Thread and Statistics History Data

If history data is available, establish the time preceding the exception condition
and use the HISTORY function to replay events. If it is a subsystem problem,
focus attention on the statistics history information. If it is an application-related
problem, identify the exception thread and display the Thread Detail panel for
that thread. Once you are in the Thread Detail Panel use the DIAGNOSE
command.
The Thread Detail Panel presents information in real time or displays history
information. In either mode these important options are available:
• SQL statement and package or DBRM
• Explain
• Locked resources.
For a suspected SQL access path problem, select the SQL statement and
package or DBRM option to obtain information on the currently executing SQL
statement and statement number. From here you can execute the EXPLAIN
command, which displays the access path chosen and additional information on
the Explain Output Panel.

For a suspected locking problem, select Locked Resources from the Thread
Detail Panel to obtain information about the lock held by the thread, the lock′ s
state, duration and the type of lock taken, and most importantly, whether the lock
is suspended. If you find that the lock is suspended, select the resource
identified as suspended. An additional panel displays the holders and waiters on
the resource.
3.11.6 Diagnose
Diagnose identifies the constraints acting on a thread and causing degradation
of its performance and makes recommendations to aid problem resolution.
Diagnose is a powerful function providing very useful information and help and
should always be used at this early stage of problem determination. Its early
use, and the function it provides, can defer the involvement of your most highly
skilled DB2 professionals. The information and recommendations that the
diagnose function provides gives enough direction so that less highly skilled DB2
professionals can resolve the problem.
3.11.7 Detailed Reports

It may become apparent that, to fully identify and resolve the problem, additional
and more detailed reports are required. It is quite probable that you have not
collected trace data for more detailed reports as part of your monitoring policy.
Therefore plan to gather the required information by using the Collect Report
Data facility.
3.11.8 Problem Occurring or Recreatable: DIAGNOSE

If the data collector is not active when the exception condition occurs, you do not
have any history data available to help diagnose the problem. However, if the
problem can be easily recreated, use the DB2 PM Collect Report Data facility.
3.11.9 Configure Collect Task

Currently active threads in exception status or regularly repeating exceptions
can use the diagnose function to help identify problems and provide
recommendations. However, if the problem recurrence is sporadic, you may
want to capture trace data for report generation by using the Collect Report Data
facility. You should configure a collect task by specifying that the traces should
be triggered immediately.
Online Monitor User ′ s Guide , Chapter 10, “Collecting Performance Data for
Reporting” or the IBM DATABASE 2 Performance Monitor for MVS (DB2 PM)
Version 4 Batch User ′ s Guide , Chapter 3, “Collecting Performance Data” for
details.
3.11.10 Accounting and Statistics Reports

Plan to collect accounting and statistics trace records to enable accounting and
statistics reports to be produced. Remember, the majority of all problems can
be identified and resolved with accounting and statistics reports. If the
accounting or statistics reports identify that more specific reports and more
detailed information is required, again use the Collect Report Data facility.
64 DB2 PM
3.11.11 Switch SMF or Process Active SMF
If the problem is not instantly recreatable and some action is required to identify
the exception cause, processing data from SMF is an option. Depending on your
installation′s procedures regarding SMF, you can make available recent past
SMF data in the active SMF data sets by issuing an MVS command to switch the
currently active SMF data set. This activity typically would be performed by your
operations staff or the MVS systems programmer. In some installations the SMF
data is read directly from the active SMF data set, but this method is not
recommended. You can generate accounting and statistics reports from the SMF
data. For more detailed reports, use the Collect Report Data facility, which
provides the necessary trace records for report generation.
3.11.12 Set Up Exception Triggers

For installations where the processing of recent SMF data is not possible, use
the Collect Report Data facility in conjunction with an exception threshold data
set.
Configure the collect task to trigger automatic trace activation following the
detection of an exception event, and turn off the trace once the thread has
terminated. However, remain logged on and within the DB2 PM environment to
allow automatic trace triggering because, in this case, the data collector is not
active (see 3.8.3, “Collection Dependencies” on page 54).
Use the collected trace data to produce accounting and statistics reports. If after
further analysis more detailed reports are required, reconfigure the Collect
Report Data facility and arrange to gather the appropriate trace records.

66 DB2 PM
Chapter 4. Using DB2 PM for Periodic Monitoring
This chapter describes periodic monitoring and explains how it can help you
maintain good DB2 subsystem performance.
Consistent, responsive service is vital in today′s interactive transaction

processing environment. Meeting this demand requires close scrutiny of all
aspects of DB2 subsystem performance and effective methods of information
gathering and problem resolution.
The purpose of periodic monitoring is to ensure the stability of the of the

production environment in its broadest sense. The information gathered from
periodic monitoring enables you to make decisions that affect the future
performance of your DB2 subsystem. Analyzing this information can identify
trends, which, if ignored, could lead to degraded performance of transactions or
the DB2 subsystem itself. View periodic monitoring as a proactive activity that
gives you the opportunity to identify potential performance situations before they
become an issue. The DB2 PM graph function provides a means of pictorially
representing trends in an easy-to-understand graphical format.
Periodic monitoring requires that the personnel responsible for the performance
and monitoring of the DB2 subsystem dedicate time at each iteration of the
monitoring cycle. Therefore the amount of information presented should be
relevant and precise. With DB2 PM you can produce reports that specifically
identify exception events, generate accounting TOP or accounting TOP ONLY
reports to show threads using the most resources, and tailor reports to your
requirements.
Plan to produce simple, meaningful reports that identify only those situations that
require action. A 40-page report depicting a healthy system is a waste not only
of your time but also of system resources.
4.1 Monitoring Frequency

Develop and document a strategy for periodic monitoring. This strategy should
be flexible, and you should be prepared to alter elements of the strategy as your
environment changes. One of your main considerations is the frequency at
which you monitor your DB2 subsystem. Do not set a frequency that is so
aggressive that you do not have time to review the reports. Plan to monitor
once a day the DB2 subsystems that are critical to your business and perhaps
less frequently for the development and test environments.
The following factors can influence your monitoring frequency:

• New application added to existing DB2 subsystem
• Additions or removal of system hardware
• Growing data volumes
• Increase in user base
• New software releases, application or system.
With mature unchanging systems you can plan to relax the monitoring frequency
and focus on examining trends to keep your “finger on the pulse.”

4.2 Report Generation
We recommend that you start your DB2 subsystem with DB2 accounting and
statistics traces activated. The classes required for basic reporting are:
• Accounting trace classes 1, 2, and 3
• Statistics trace classes 1 and 3.
You can have both accounting and statistics traces start automatically by
specifying the options for the SMF ACCOUNTING and SMF STATISTICS fields on
the DB2 DSNTIPN installation panel.
Collecting accounting and statistics trace information always provides the

capability for generating accounting and statistics reports.
Plan to produce accounting and statistics exception reports. These reports

ideally should contain no, or very few, entries, assuming your exception
thresholds have been set correctly. See 3.6.3.1, “The System Programmer” on
page 46 and 3.6.3.2, “The Database Administrator” on page 47 for a discussion
on determining exception threshold data set entries and values.
We also recommend that you run accounting and statistics reports in conjunction
with the accounting and statistics exception reports.
In addition we suggest that you:

• Generate deadlock traces regularly. In this way detailed information is
immediately available if the need to investigate a locking problem arises.
These reports do not require additional traces and are available from trace
information collected by statistics trace class 3.
• Use accounting TOP reporting to identify threads with the largest resource
usage or the greatest wait time due to contention.
DB2 PM analyzes performance data to create reports and graphs that give you a
clear, complete picture of overall DB2 subsystem performance. See 4.3,
“Collecting DB2 Performance Data” for a discussion concerning collection of
performance data. The graphs are presented in terms of workload activity,
utilization, and responsiveness, focusing on DB2 subsystem, connection, and
plan utilization and storage and I/O resources.
4.3 Collecting DB2 Performance Data

The Instrumentation Facility Component (IFC) gathers information about events in
the DB2 subsystem. DB2 PM reads these IFC records and on request can
generate reports and graphs, populate data sets, and write the reformatted and
filtered data in an internal format to a data set (referred to as DPMOUT) for later
reprocessing. Once DB2 PM processing is completed, you can either discard the
input (SMF or GTF) or archive it, if required, for use with other non-DB2
monitors.
68 DB2 PM
4.3.1 SMF
SMF is used for continuous monitoring. It is the default destination for statistics,
accounting, and audit traces.
Data directed from DB2 to SMF can get lost. The most common reason is that
SMF buffers overflow. If your system is likely to generate a large quantity of
records over a short time period, consider increasing the SMF buffer size and
the SMF data set size.
In addition to specifying the DB2 trace classes for activation ensure that DB2 can
direct records to SMF. Your system programmer can validate that the following
SMF record types are active:
• SMF record type 100 (statistics trace records)
• SMF record type 101 (accounting trace records)
• SMF record type 102 (performance and audit trace records).
The SMF dump utility can select DB2 record types from an SMF dump data set
by filtering on SMF record types 100, 101, and 102 before DB2 PM handles the
data.
4.3.2 GTF
You can direct the DB2 IFC records to GTF if you expect to generate large
volumes of data (for example, you may want to collect detailed SQL information).
However, be aware that GTF operates on a wraparound basis. When the end of
the GTF file is reached GTF repositions at the beginning of the file and starts
overwriting previously recorded data. Ensure that the GTF file is large enough to
contain the required data.
One of the benefits of using GTF is that the trace records are immediately
available for processing once the GTF trace is stopped.
4.3.3 DPMOUT Data Sets

If you want to reprocess the same DB2 PM data to generate a number of
different reports, consider using the DPMOUT records as input, especially if the
SMF or GTF data set is large.
There is a cost in producing DPMOUT records, so consider your requirements

before deciding to use DPMOUT. If you do not specify a DPMOUTDD statement in
the JCL, only the records required for the current job step are processed.
Broadly speaking, if you intend to produce one report, and it is unlikely that you
will reuse the data, do not use DPMOUT. If, however, your requirement is to
produce a number of reports at different times using the same input data,
consider using DPMOUT. The DB2 PM records required for reports will already
have been stripped and sorted from the SMF data set and placed in your
DPMOUT data set. This form of input data is far superior, in terms of
performance, to the method of reprocessing raw SMF data for each report
iteration.
To gain further benefit from DPMOUT processing specify the GLOBAL command
in the DB2 PM command stream because only the records that pass GLOBAL
processing go into the DPMOUT data set. Use the PRESORTED(ENFORCE) option
on the GLOBAL command. Producing DPMOUT records implicitly sorts the
Chapter 4. Using DB2 PM for Periodic Monitoring 69

records in the correct sequence, so there is no requirement to perform another
internal sort. PRESORTED(ENFORCE) disables the internal sort.
4.3.4 DB2 PM Collect Task

The DB2 PM Online Monitor collect task enables performance data to be written
to a user-defined data set, the collect task data set. The collect task is
configured from the Collect Report Data option. It is particularly useful in
situations where problems either recur naturally or can be recreated, and your
requirement is to capture detailed information that is not typically available
through the default traces.
There are additional benefits in collecting trace information to the collect task
data set. You potentially avoid flooding SMF or GTF with a large number of
records, and you make the trace data immediately available without affecting
SMF of GTF record collection. You do not need to be able to issue operator
commands associated with SMF and GTF functions (which is an authorization
issue in many cases), and you do not need to synchronize what you are doing
with an operator.
To collect data, you must have the necessary DB2 privileges to start and stop
DB2 traces. When DB2 PM attempts to start the traces for the specified report
on your behalf, your primauth is passed to DB2 for authorization checking.
To collect performance data, first configure a collect task and then specify the
type of data you require, the trace start and stop criteria, and the output data set
name. The collect task triggers the appropriate DB2 trace to start writing the
collected data to a data set and stops the trace when the criteria you specify has
been matched.
You can configure up to four independent collect tasks. With each task, you can
collect specific data types, IFCIDs, and limit the volume of data by requesting
specific location, plan name, and authorization ID.
Using the data collector you can configure DB2 traces to start:
• At a specified time of the day
• When a specified periodic exception is detected
• When a specified exception event occurs
• Immediately.
You can see that there are various levels of sophistication for starting traces.
However, let us consider the collection of trace data for an infrequent problem
that occurs overnight. To capture very detailed trace data and ensure that the
SMF buffers are not flooded, an experienced person must be on site to start the
traces at the appropriate time and terminate the traces once the problem occurs.
It is quite possible that the problem will not occur for several nights. This
situation is not only very inconvenient but also expensive to support.
By using the DB2 PM collect task you can turn on the selected traces
automatically through the detection of either a periodic or event exception,
previously defined, and turn off the trace when the thread terminates, after a
specified elapsed time or after a specific IFCID has been collected a number of
times.
70 DB2 PM
Be aware that, like SMF and GTF, a collect task can lose data. The data loss
can occur because DB2 moves the trace records to a circular buffer in memory.
When there is more data than a threshold that the collect task specifies, the
collect task is posted, wakes up, and copies the data back into its own address
space. The TSO user who is running at a lower dispatching priority than the DB2
address space copies the records. If DB2 is writing data at a rate that is faster
than a rate with which the user can cope, the data is lost when the buffer wraps
around. The user can change the buffer size to avoid data loss.
The data that the collect task collects can be used as input to DB2 PM batch
jobs, and the reports generated can be made available when support personnel
arrive in the morning. There is no disruption to your operations personnel, and
no risk that your system will be affected for an extended period because of
detailed trace data collection.
Batch User ′ s Guide , Chapter 3, “Collecting Performance Data” for detailed
information about configuring a collect task and gathering trace data
automatically.
4.4 Exception Reporting

The exception report simplifies the performance management task. Correctly set
exception thresholds alert you to situations generating warning thresholds,
allowing you to make plans for remedial action. It is possible that you also
receive problem exceptions, but these should be only few in number.
The most important factors in exception detection are identifying the correct
fields and supplying the appropriate threshold values. Recommendations for
setting exception thresholds are discussed in detail in 3.6, “Setting Exception
Thresholds” on page 44.
Plan to produce both accounting and statistics exception reports every day and
make these the focus of your attention. If exceptions are identified, you should
examine the batch accounting and statistics reports. These reports should
provide a good pointer to or in many cases identify the cause of your exception.
You can develop and use a number of exception threshold data sets for report
generation. For example, you can have one exception threshold data set that
identifies specific plans critical to the business, focusing on elapsed time. This
data set can be useful in reporting exception events for the previous online day.
You can have another exception threshold data set that reports exceptions from
overnight batch processing. Each exception threshold data set identifies
exception fields and thresholds to be used in specific circumstances.
There is no limit to the number of exception threshold data sets that you
develop. You will find it very useful to have specific threshold data sets tailored
for use with certain plans, connection types, correlation IDs, or primauth IDs.
Having stated the above, we would also like to point out that you can define
different exceptions for different applications (actually, plans) in one exception
threshold data set, thus eliminating the need to ″switch″ exception threshold
data sets if you have a mixed workload.

You will probably have at least two exception threshold data sets, one that you
develop over time to monitor your system, and another that you create when
required to investigate specific problems.
The accounting exception report is easy to read (see Figure 25). It provides
accounting report information for threads that are in exception and includes the
exception messages block for each exception.
LOCATION: ST11DB2F DB2 PERFORMANCE MONITOR (V4) PAGE: 1-1

GROUP: N/P ACCOUNTING REPORT - SHORT REQUESTED FROM: NOT SPECIFIED
MEMBER: N/P EXCEPTION TO: NOT SPECIFIED
SUBSYSTEM: DB2F ORDER: PRIMAUTH-PLANNAME INTERVAL FROM: 04/20/95 14:45:35.08
DB2 VERSION: V4 TO: 04/20/95 14:55:15.00
PRIMAUTH #OCCURS #ROLLBK SELECTS INSERTS UPDATES DELETES CLASS1 EL.TIME CLASS2 EL.TIME GETPAGES SYN.READ LOCK SUS
PLANNAME #DISTRS #COMMIT FETCHES OPENS CLOSES PREPARE CLASS1 CPUTIME CLASS2 CPUTIME BUF.UPDT TOT.PREF #LOCKOUT
--------------------------- ------- ------- ------- ------- ------- ------- -------------- -------------- -------- -------- --------
DB2RES2 1 0 0.00 0.00 0.00 0.00 1:05.080300 18.431857 7128.00 0.00 0.00
DSNTEP41 0 1 13.0K 1.00 1.00 1.00 38.428172 14.175631 5688.00 396.00 0
-------------------------------------------------------------------------------------------------------
|PROGRAM NAME TYPE #OCCURS SQLSTMT CL7 ELAP.TIME CL7 CPU TIME CL8 SUSP.TIME CL8 SUSP|
|DSNTEP2 PACKAGE 1 13.0K 18.431792 14.175577 3.332170 90.00|
-------------------------------------------------------------------------------------------------------
**********************************************************************************************************************************
* TYPE FIELD ID FIELD DESCRIPTION BY VALUE THRESHOLD *
* FIELD QUALIFIER *
* PROBLEM ADDB2ETT ELAPSED TIME IN DB2 (CLASS 2) THREAD 18.431857 > 16 *
* *
**********************************************************************************************************************************
Figure 25. Accounting Short Exception Report
4.5 Tailored Reports

The default layouts that DB2 PM provides for the accounting and statistics
reports and traces should meet your requirements most of the time. However, if
you have to create your own layouts, you can use the user-tailored reporting
(UTR) feature.
The UTR feature can be particularly useful if you want to remove fields from a
report for which you have no responsibility, reduce the volume of data to
highlight key fields, or provide more detail concerning particular aspects of the
report. With the UTR feature you can:
• Add entire blocks and individual fields to an existing layout
• Remove entire blocks and individual fields from an existing layout
• Change the relative positions of blocks and fields in an existing layout
• Change block and field labels.
The following reports and traces support UTR:

• Accounting report
• Statistics report
• Accounting trace
• Statistics trace.
72 DB2 PM
Figure 26 on page 73 shows the JCL that includes the statements required to
use the UTR feature.
//STSGMGTR JOB (G8668701),¢DB2PM¢,CLASS=2,MSGCLASS=X,

// REGION=4096K,NOTIFY=STSGMG
//PMV300 EXEC PGM=DB2PM
//INPUTDD DD DSN=SYSMF.D1.DAILY.DATA.G0001V00,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//STRPTDD DD SYSOUT=*
//DPMPARMS DD DSN=STSGMG.DB2PM.DPMPARMS /* user DPMPARMS data set */
//SYSIN DD *
STATISTICS
REDUCE
FROM(04/10/95,13:00:00.00)
TO(04/10/95,19:00:00.00)
INTERVAL(60)
BOUNDARY(0)
REPORT
LAYOUT(BUFFER) /* modified UTR report */
ORDER(INTERVAL)
EXEC
Figure 26. JCL for User-Tailored Reporting Feature
DB2 PM uses default profiles for the creation of standard report sets, for
example, the accounting short report. The profiles for your tailored report reside
in a partitioned data set created and owned by you. Save the profiles with
meaningful names because you refer to them when report layouts are
generated.
You must name the data set in which you plan to save your user-tailored profile
on the User-Tailored Report Layout Generation panel. To use your own tailored
profiles, you must identify the data set in which they reside to DB2 PM.
The DPMPARMS DD statement identifies the data set containing the UTR
profiles, and the LAYOUT option identifies the specific profile to be used for the
trace or report.
For a detailed explanation of user-tailored reports and a panel walkthrough to

produce a user-tailored profile, see the IBM DATABASE 2 Performance Monitor
for MVS (DB2 PM) Version 4 Batch User ′ s Guide , Chapter 8, “Customizing DB2
PM Functions.”
Figure 27 on page 74 shows a sample user-tailored accounting report.

Additional information regarding class 3 suspension times has been added to the
standard accounting report.

GROUP: N/P ACCOUNTING REPORT - CLASS3 REQUESTED FROM: NOT SPECIFIED
MEMBER: N/P TO: NOT SPECIFIED
DB2 VERSION: V4 TO: 04/20/95 14:55:15.00
--------------------------- ------- ------- ------- ------- ------- ------- -------------- -------------- -------- -------- --------
DB2RES2 1 0 0.00 0.00 0.00 0.00 1:05.080300 18.431857 7128.00 0.00 90.00
DSNTEP41 0 1 13.0K 1.00 1.00 1.00 38.428172 14.175631 5688.00 396.00 0
CLASS 3 SUSP. AVERAGE TIME AV.EVENT

-------------- ------------ --------
LOCK/LATCH 0.011651 70.00
PAGE LATCH 0.000000 0.00
SYNCHRON. I/O 0.000000 0.00
OTHER READ I/O 1.862330 12.00
OTHER WRTE I/O 1.458189 8.00
SER.TASK SWTCH 0.000000 0.00
TOTAL CLASS 3 3.332170 90.00
Figure 27. User-Tailored Accounting Report
4.6 Accounting TOP Reporting

The accounting TOP option is used to draw your attention to entries that might
indicate a problem. You may want to use the accounting TOP option for capacity
planning purposes, monitoring users, plans, and transactions consuming the
most resources.
4.6.1 Accounting TOP ONLY

You can choose, for example, to view the top 20 users of high class 1 elapsed
time. This information is presented in one accounting report, with entries only
for the top 20 users. Figure 28 shows the syntax for the TOP ONLY keyword.
ACCOUNTING
REPORT
ORDER(PRIMAUTH-PLANNAME)
TOP (20 ONLY INAPPLET)
Figure 28. Accounting TOP ONLY Syntax
Figure 29 on page 75 shows the Accounting TOP ONLY report with accounting
entries for the first and last users from the top 20 users of high class 1 elapsed
time.
74 DB2 PM
************************************************************************************************************************
DB2 VERSION: V4 TO: 04/17/95 15:32:32.12
TOP FIELD: ELAPSED TIME SPENT IN APPLICATION TOP NUMBER REQUESTED: 20
--------------------------- ------- ------- ------- ------- ------- ------- -------------- -------------- -------- -------- --------
DB2RES3 15 1 0.00 0.00 0.00 0.00 10:00.816057 4:54.158991 42445.20 3849.33 1.40
DSNTEP41 0 14 430.4K 1.00 0.93 1.00 4:44.619477 2:24.916830 31072.93 5473.33 0
--------------------------- ------- ------- ------- ------- ------- ------- -------------- -------------- -------- -------- --------
18 report occurrences not shown
--------------------------- ------- ------- ------- ------- ------- ------- -------------- -------------- -------- -------- --------
DB2RES2 4 0 0.00 0.00 0.00 0.00 51.572334 12.581559 4308.00 0.00 0.00
DSNTEP41 0 4 12.2K 1.00 1.00 1.00 33.339927 10.673360 2796.00 224.50 0
Figure 29. Accounting TOP ONLY Report
4.6.2 Accounting TOP

You can produce a normal accounting report for all data collected, with a list of
the top 20 users of high class 1 elapsed time shown at the end of the report.
This list is an immediate indicator of the highest 20 users of class 1 elapsed time
as well as an index pointer to the pages in the report containing more detailed
information. Figure 30 shows the syntax for the TOP keyword.
ACCOUNTING
REPORT
ORDER(PRIMAUTH-PLANNAME)
TOP (20 INAPPLET)
Figure 30. Accounting TOP Syntax
Figure 31 on page 76 shows the last page of the accounting report indicating the
first and last top 20 users of high class 1 elapsed time.

************************************************************************************************************************************
1 LOCATION: ST11DB2F DB2 PERFORMANCE MONITOR (V4) PAGE: 1-2
DB2 VERSION: V4 TO: 04/17/95 15:32:32.1
PRIMAUTH
PLANNAME VALUE PAGE
---- -------------------------------------------------------- --------------- ----
DB2RES3
1 DSNTEP41 10:00.816057 1-1
--------------------------
18 TOP entries not shown
--------------------------
DB2RES2
20 DSNTEP41 51.572334 25-1
Figure 31. Accounting TOP List
4.7 Graphs
Graphical data is most useful for the presentation of trend analysis. To use a
graph to determine the difference between the amount of synchronous I/O and
prefetch I/O for an exception that occurred the previous evening, would be
inappropriate; an accounting report would be more appropriate. However, to
check whether a general trend is developing between TCB class 1 time and
elapsed class 1 time would require an analysis of several days or perhaps two
weeks of data. In this situation it would be time consuming to process a number
of accounting reports when the GRAPH function can represent the information in
a clear and easy-to-understand format.
4.7.1 Input Data

If you plan to use the graph function to provide trend analysis, consider
collecting the data on a regular basis. You must have an even and
representational cross section of input data to provide accurate trend analysis.
Graphs are produced from direct interaction with a sequence of DB2 PM panels,
starting with the Graphics Selection Menu (see Figure 32 on page 77).
76 DB2 PM
Graphics Selection Menu
1. Accounting by field identifiers

2. Accounting by DB2 PM identifiers
3. Statistics
4. Frequency distribution
Command ===> ____________________________________________________________

F1=Help F3=Exit F6=Recall F10=Chart F12=Cancel
Figure 32. Graphics Selection M e n u
One of the requirements for graph generation is the inclusion of the saved output
generated by invoking accounting and/or statistics reduce and save functions.
This saved output resides in VSAM data sets that you define and is subsequently
used as input for the graph generation process.
The default DDNAMEs for both accounting save and statistics save VSAM data
sets are ACSAVDD and STSAVDD, respectively. Appendix B, “DB2 PM Data
Sets” on page 185 provides information regarding the allocation of these and
other important data sets.
You can also produce graphs from the distributed file created from the
processing of the DISTRIBUTE command.
You may want to produce graphs using perhaps a week′s worth of saved data to
check for unusual trends. Use the method described below in conjunction with
the normal daily production of an accounting and statistics report.
To collect both accounting and statistics save data for a period of several days,
use the Interactive Report Selections panel in Figure 33 on page 78, which
shows the Reduce, Report, and Save functions selected for both Accounting and
Statistics.

Interactive Report Selections
Command ===> ____________________________________________________________
Select functions as required, then press Enter.
Report Set --------------- Function ---------------

Reduce Report Trace File Save Restore
Accounting . . . . . . > > _ _ > _
Statistics . . . . . . > > _ _ > _
SQL Activity . . . . . _ _ _
Locking . . . . . . . _ _ _ _
I/O Activity . . . . . _ _
Audit . . . . . . . . _ _ _ _
Utility . . . . . . . _ _ _
Record Trace . . . . . _ _
Additional Functions
Global Processing . . . . . . . . . . . _
Frequency Distribution . . . . . . . . . _
System Parameters . . . . . . . . . . . _
Exception log . . . . . . . . . . . . . _
Explain . . . . . . . . . . . . . . . . _
F1=Help F3=Exit F5=Compose F6=Browse F10=Global F11=Inc

F12=Cancel
Figure 33. Interactive Report Selections Panel
Figure 34 shows the JCL generated for the selections in Figure 33.

//ACRPTDD DD SYSOUT=*
//ACSAVDD DD DSN=STSGMG.DB2PM.ACSAVDD,DISP=SHR
//STSAVDD DD DSN=STSGMG.DB2PM.STSAVDD,DISP=SHR
//SYSIN DD *
ACCOUNTING
REDUCE
FROM(04/10/95,13:00:00.00)
TO(04/10/95,19:00:00.00)
REPORT
DDNAME(ACRPTDD)
SAVE
DDNAME(ACSAVDD)
STATISTICS
REDUCE
FROM(04/10/95,13:00:00.00)
TO(04/10/95,19:00:00.00)
REPORT
DDNAME(STRPTDD)
SAVE
DDNAME(STSAVDD)
EXEC
Figure 34. JCL for Accounting and Statistics Reduce, Report, and Save
78 DB2 PM
Follow these steps to collect accounting and statistics save data:
1. Define both accounting save and statistics save data sets. Ensure the data
sets are large enough to contain the desired amount of data.
2. Decide on an appropriate interval for your graph. If you plan to have graphs
at the end of the week, use the defaults interval(0) and boundary(0) to
produce graphs that have data summed every day of the week. Choose other
values for interval and boundary if you want to produce graphs more
frequently during the week.
3. Generate JCL from the DB2 PM Interactive Report Selections panel to
include the save function.
4. If the VSAM save data set is empty, schedule the job to populate the save
data set.
5. If this is a second or subsequent iteration, include:
• RESTORE DDNAME(ACSAVDD) for accounting
• RESTORE DDNAME(STSAVDD) for statistics.
6. Save the generated job stream for inclusion in some form of daily automated
job scheduler.
This procedure will have the effect of adding subsequent save records to the end
of the respective accounting or statistics save VSAM data sets.
The RESTORE subcommand enables previously saved data to be combined with

saved data from subsequent runs. Figure 35 on page 80 shows the JCL that
includes the RESTORE subcommand.

//ACSAVDD DD DSN=STSGMG.DB2PM.ACSAVDD,DISP=SHR
//ACRSTDD DD DSN=STSGMG.DB2PM.ACSAVDD,DISP=SHR
//STSAVDD DD DSN=STSGMG.DB2PM.STSAVDD,DISP=SHR
//STRSTDD DD DSN=STSGMG.DB2PM.STSAVDD,DISP=SHR
//SYSIN DD *
ACCOUNTING
REDUCE
FROM(04/10/95,13:00:00.00)
TO(04/10/95,19:00:00.00)
RESTORE
DDNAME(ACRSTDD)
REPORT
DDNAME(ACRPTDD)
SAVE
DDNAME(ACSAVDD)
STATISTICS
REDUCE
FROM(04/10/95,13:00:00.00)
TO(04/10/95,19:00:00.00)
RESTORE
DDNAME(STRSTDD)
REPORT
DDNAME(STRPTDD)
SAVE
DDNAME(STSAVDD)
EXEC
Figure 35. JCL for Accounting and Statistics Reduce, Restore, Report, and Save
4.7.2 Accounting by Field Identifier Graph

You can use the accounting by field identifier graphs to compare the values of
different accounting fields or analyze the performance of one group of
transactions over a time interval to determine trends. You can plot up to four
accounting fields for the group. For example, you might want to graph the
elapsed and CPU times for a particular combination of connection name, plan
name, and authorization ID to determine the elapsed time pattern. Figure 36 on
page 81 shows an example of an accounting by field identifier graph. The graph
shows the class 1 elapsed time for plan FLHPE1TC, and you can see that the
average for day 04/23 was high at nearly 2 seconds. By including the class 3
suspension time it becomes immediately evident how the class 3 suspension
time has affected the class 1 elapsed time. The graph also shows that the
problem was unusual, as this situation was not repeated, and therefore a
problem trend was not identified.
80 DB2 PM
Figure 36. Accounting by Field Identifier Graph
4.7.3 Accounting by DB2 PM Identifier Graph

Use the accounting by DB2 PM identifier graph to analyze the performance of up
to four groups of transactions for one field over a period of time. You can use
the graph to determine whether one transaction is adversely affecting another.
You can, for example, produce a graph of the elapsed times for four different
connection name and plan name combinations.
Figure 37 on page 82 and Figure 38 on page 82 show examples of an

accounting by DB2 PM identifier graph. The graph in Figure 37 on page 82
shows how over a 24-hour period the class 2 TCB time was used by three
related transactions. Clearly, during the period 12:00 to 16:00, something
unusual occurred that caused the class 2 TCB time to increase dramatically.

Figure 37. Accounting by DB2 PM Identifier Graph: TCB
The graph in Figure 38 shows that during the same time period (12:00 to 16:00)
the two affected transactions had high SQL activity, thus explaining the sudden
increase in class 2 TCB time.
Figure 38. Accounting by DB2 PM Identifier Graph: SQL
82 DB2 PM
4.7.4 Statistics System Graph
Use the statistics system graph to compare up to four statistics fields against
time. You can use the graph to monitor systemwide DB2 resource usage trends.
Figure 39 shows an example of a statistics system graph. The period 04/17 was
a holiday, which explains the low activity on that date. The DB2 system was
restarted, and the graph shows that on 04/18 most requests for PTs were not
found in the EDM pool. During the next three days a much higher ratio of PTs
was found in the EDM pool even though the request demand stayed high. There
is an improving trend for a five-day period.
Figure 39. Statistics System Graph
4.7.5 Frequency Distribution Graph

Use the frequency distribution graph to plot the distribution of a selected field
across user-specified ranges. To produce the data used as input to the graph
use the DISTRIBUTE command. Frequency distributions can help you locate
unusual values by dividing events into ranges. The graph can help you to
determine quickly whether the majority of the application executions have a
performance problem, and if so, how many of the application executions were in
each elapsed time range.
The graph in Figure 40 on page 84 shows accounting by field identifier graph for
class 1 elapsed time.

Figure 40. Accounting by Field Identifier Graph for Comparison with Freq Dist Graph
During the online day high average values are reported during a period
spanning 12:00 to 14:00 for the FLHPE1TB plan. To examine the makeup of the
average values, use a frequency distribution graph.
The strength of the frequency distribution graph is in pinpointing excessive

values that would otherwise be hidden in report averages. Figure 41 on
page 85 shows, for the 12:00 to 14:00 period, a breakdown of the number of plan
occurrences distributed within class 1 elapsed time boundaries specified in
millisecond units.
84 DB2 PM
Figure 41. Frequency Distribution Graph
For information on editing, printing, and saving graphs, refer to the Graphic Data
Display Manager/Presentation Graphics Feature: Interactive Chart Facility User′ s
Guide .
4.8 MAINPACK and PACKAGE Identifiers

MAINPACK is used to distinguish plans according to the packages they contain.
The representative package is either the first or last package or the DBRM
executed within a plan. This identifier is useful when the name of a plan does
not provide satisfactory identification, for example, reporting database access
thread (DBATs) initiated by remote requesters that have the same plan name,
DISTSERV, at the server site.
The default definition for MAINPACK is the package ID of the first executed
package. The MAINPACK definition is stored in the DPMPARMS member,
MAINPACK. You can tailor MAINPACK to your requirements by accessing the
MAINPACK Definition Member Editor by selecting option 4, Maintain MAINPACK
definitions, on the Data Set Maintenance Menu in the IRF. MAINPACK can be
used in INCLUDE/EXCLUDE and ORDER processing.
PACKAGE is used to identify a package regardless of the plan to which it

belongs. PACKAGE can be used in INCLUDE/EXCLUDE and ORDER processing.
Ordering by PACKAGE, in an accounting report, distinguishes between

executions of large plans. You might have a large plan consisting of many
packages that are used by a number of different transactions, and you might
want to see the resource utilization for each package or DBRM. If you use
ORDER(PACKAGE), DB2 PM reports information for all packages regardless of
the plans under which the packages or DBRMs are executed and summarizes

the information into a report by individual package. Remember that you should
start accounting trace classes 7 and 8 to get information about packages.
Batch User ′ s Guide, Chapter 8, “Customizing DB2 PM Functions” for more
details and examples.
4.9 Correlation Identifier

The correlation ID generated by DB2 is translated into the DB2 PM identifiers
CORRNAME and CORRNMBR as per Table 5. For example, you can generate an
accounting report for CICS transactions ordered by CICS transaction ID by
specifying ORDER(CORRNMBR) in the DB2 PM command stream. If you want to
change the DB2 PM default settings, use the correlation translation facility.
Table 4. The 12-Byte Correlation ID Field and the Default Translation

Connection 1 2 3 4 5 6 7 8 9 10 11 12
Batch CORRNAME (job name) CORRNMBR (blank)
TSO, DB2 call attachment facility CORRNAME (origauth) CORRNMBR (blank)
(CAF)
CICS CORRNMBR CORRNAME (pool
(transaction ID) thread)
IMS CORRNMBR (appl, CORRNAME (appl, PST)
PSBNAME)
4.10 Time Zone Specification

If the CPU clock of your MVS system is not set to the local time and you want to
have the local times shown in the DB2 PM reports, or you want to produce DB2
PM reports and traces showing activity at more than one location and the CPU
clock settings of these locations are different, use the DB2 PM time zone
specification feature.
4.11 Solving Periodic Exceptions Using DB2 PM

This section provides a structured approach to solving periodic exceptions by
using DB2 PM. The approach is not likely to fit all problem situations, but it can
serve as a guideline on which you can base your policy for periodic monitoring
and problem resolution.
Figure 42 on page 87 shows the sequence of actions you can take to resolve a
number of problem situations. Use the diagram in conjunction with the text in
this section. The text expands on the elements in the diagram, suggests
underlying causes of the problem, and recommends which reports to run.
86 DB2 PM
------------- ------------- -------------
|Accounting-| |Statistics-| |Locking- |
|Exception | |Exception | |Lockout |
---|Report, |-|Report, |-|Trace |----
| |Report with| |Report | | | |
| |TOP lists, | | | | | |
| |TOP ONLY | | | | | |
| ------------- ------------- ------------- |
------------- ------------
|Application| | DB2 |
---------| Problem |--------- |Subsystem |
| ------------- | | Problem |
----------- | ------------
| High | | |
| Class 1 | | |
| Elapsed | | ------------
| Time | | | Examine |
----------- | |Statistics|
| | | Report |
------------- ----------- ------------
Y | Low | N |Timeouts |
---| Class 2 |--- | and |
| | Elapsed | | |Deadlocks|
| | Time | | -----------
| ------------- | |
------------- ------------ ----------- ------------
|Network and| Y | High | N |Lockout | | SQL |
|Transaction|----| Class 2 |---- |Trace or |----| Activity |
|Manager | | | TCB | | |Report | | Report |
|Reports | | | Time | | ----------- ------------
------------- | ------------ |
| |
----------- ----------- ------------ ----------
| High | | High | N |Not | | RMF |
| SQL | | Class 3 |-----|Accounted |---| Report |
|Activity | |Wait Time| | | | |
----------- ----------- ------------ ----------
| |Y
----------- ------------
| Explain | Y | High | N
| | ----|Lock/Latch|------------------
----------- | | Time | |
| | ------------ |
----------- | |
| SQL | | |
|Activity | | |
| Report | | |
----------- | |
| |
-------------- -------------- -------------- -----------
Y |Can Recreate| N | High I/O |---------| Statistics |--| RMF |
----|the Problem |---- ----| Suspension |---- | Report | | Report |
| | Now? | | | | Time | | -------------- -----------
| -------------- | | -------------- |
| | ------------ -------------
----------- --------------- |Unexpected| |Unexpected |
|Collect | |Trigger Trace | |Prefetch | ---|Synchronous|----
|Trace | |Data Collection| | | | |I/O | |
|into UDS | |by Exception | ------------ | ------------ |
----------- ----------------- | | |
| | | | |
| ------------ | ----------- -------------- -----------
| | Lock | | | Access | | Sequential | | Access |
|--->|Suspension|<---| | Path | | Prefetch | | Path |
| Report | | Change: | | Disabled | | Change: |
------------ | Explain | -------------- | Explain |
----------- -----------
Figure 42. Road Map for Problem Resolution: Periodic Exceptions

The volume of data available for use in problem resolution can be overwhelming.
If its use is not controlled or understood, you may find that problem situations
are compounded. To illustrate this point, consider a locking problem that has
been identified on an exception report. You may, as your initial action, choose
to turn on a performance trace to collect trace records for generating a locking
report. The performance trace can be expensive in terms of CPU overhead and
data storage, and the generated report requires some measure of experience to
understand and identify the cause of the problem. To reduce the performance
overhead, the preferred course of action would be to produce the lockout trace
from statistics trace class 3 records. The information from the lockout trace
provides more succinct and manageable information at this initial level of
problem determination.
In short, to minimize the cost and processing overhead in problem resolution, it

is important to document your monitoring procedures and ensure that the
correct sequence of actions is followed.
The triangle in Figure 43 represents the volume of data available to DB2 PM for
use in problem determination. As DB2 PM uses data further and further below
the horizontal line truncating the triangle, the cost increases in terms of tracing
overhead, data storage requirements, CPU processing, and the human cost of
reviewing the information and identifying the problem.
/\
/ \
/ \
/ \
----------------------------
/ \
/ \
/ \
/ DB2 PM \
/ \
/ INSTRUMENTATION \
/ \
/ DATA \
/ \
/ \
/ \
/ \
/ \
/ \
/ \
------------------------------------------
Figure 43. Data Available to DB2 PM for Problem Determination
88 DB2 PM
By processing the volume of data represented by the area above the horizontal
line, 95% of the problems can be solved, or the cause of the problems identified.
This volume of data represents that required for the production of the accounting
and statistics report set.
By analyzing the accounting and statistics reports, with some experience you
can identify the cause of problems and make recommendations for problem
resolution. The information obtained from these reports may indicate, on
occasions, that you have to produce more detailed reports to identify the cause
of the problem. However, by identifying a specific time period, plan name or
primauth ID in the accounting and statistics reports, you are in a better position
to reduce the volume of data you need to process.
We therefore recommend that you produce accounting and statistics reports as

part of your periodic monitoring cycle and use them as an initial starting point in
problem identification. Plan to produce the following reports regularly:
• Accounting exception report
• Accounting report with TOP lists
• Accounting TOP ONLY report
• Statistics exception report
• Lockout trace.
Once a DB2 problem has been identified, through DB2 PM facilities or some
other medium, before embarking on a detailed diagnosis of the problem,
consider any recent alterations or changes to software releases, hardware,
applications, and data volumes.
Accounting Exception Report: Review the exception report first. If your

exception thresholds are realistic, you should see few or no exceptions in
problem status but may encounter some in warning status. You can decide at
this stage to plan actions to resolve problems with warning exceptions or
monitor on a daily basis.
Accounting Report with TOP Lists: Accounting reports show thread activity and
therefore provide valuable information on application performance.
We recommend an accounting report instead of an accounting trace , because

the report is shorter and more commonly used than a trace. If a specific
problem is uncovered and the accounting report does not fulfil your needs, you
can reprocess the same input records used for the accounting report to produce
an accounting trace. The default value of zero for INTERVAL and the default
ordering sequence of primary-authorization ID and plan name may be adequate
most of the time.
Be sure to look at the TOP lists at the end of the accounting report. They will
help you focus attention on the relevant sections in the accounting report.
By default, the accounting report is in the primauth ID-plan name sequence. You
can change this sequence by using the ORDER option. For example, to see the
average elapsed time for a transaction during the online day and how the
elapsed time fluctuates on an hourly basis, use ORDER(INTERVAL-PLANNAME)
and restrict the contents of the report to the specific plan by using

INCLUDE(PLANNAME( YOURPLAN )), where YOURPLAN is the name of the plan.
Using ORDER and INCLUDE in conjunction with the reduce function, you can get
a summary of average elapsed times on the hour boundary with a grand total at
the end of the report. Figure 44 shows the JCL to achieve this.

//SYSIN DD *
ACCOUNTING
REDUCE
INTERVAL(60)
BOUNDARY(0)
REPORT
DDNAME(ACRPTDD)
INCLUDE(PLANNAME(YOURPLAN))
ORDER(
INTERVAL-PLANNAME
)
EXEC
Figure 44. Accounting Reduce and Report with Include and Order
Ordering by CONNTYPE-PLANNAME groups CICS, IMS-MPP, IMS-BMP,

DB2CALL, and TSO separately, allowing you to focus on specific areas of
interest. For more information about the ORDER option refer to the IBM
DATABASE 2 Performance Monitor for MVS (DB2 PM) Version 4 Report
Reference
Accounting TOP ONLY Report: As an additional method of analysis, use

accounting TOP ONLY reporting to identify threads with the largest resource
usage or the greatest wait time due to contention. TOP ONLY identifies these
threads even if exception conditions have not been defined for them.
Statistics Exception Report: Review the exception report first. If your exception
thresholds are realistic, you should see few or no exceptions in problem status
but may encounter some in warning status. You can decide at this stage to plan
actions to resolve problems with warning exceptions or monitor on a daily basis.
The DB2 system programmers and database administrators can use the
statistics exception report to confirm the existence of a DB2 subsystem problem
affecting applications. Many of the fields that directly affect DB2 subsystem
performance should be included in the exception threshold data set and
therefore reported in the exception report. See 3.6.3, “Fields for Populating the
Threshold Data Set” on page 45 for a discussion of the fields to consider for
exception processing.
Statistics Report: The statistics report summarizes all data between the start
and end time. If you decide to produce a statistics report covering a 24-hour
period, the report will summarize all data for that period and show, for example,
the number of getpage requests, the number of system checkpoints, and the
efficiency of the EDM pools and buffer pools for that period.
90 DB2 PM
If you require a more granular approach and want to see subsystem
performance summarized into 2 hours for a 24-hour period, use the REDUCE
subcommand to reduce and summarize records for the reduction interval you
specify. Figure 45 on page 91 shows the sample JCL to reduce data into two
hourly summarized records reported on an hourly boundary (12.00, 13.00, 14.00).

//SYSIN DD *
STATISTICS
REDUCE
INTERVAL(60)
BOUNDARY(0)
REPORT
ORDER(INTERVAL)
EXEC
Figure 45. Statistics Reduce and Report
For more information on running statistics reports refer to the IBM DATABASE 2
Performance Monitor for MVS (DB2 PM) Version 4 Batch User ′ s Guide .
Lockout Trace: The lockout trace shows timeouts and deadlocks and identifies
the holders, waiters, and resources in question.
Application Problem: Examine the accounting exception report for warning or

problem exception conditions. The exception may be application related or
caused by an underlying subsystem problem. If it is not immediately apparent
whether the problem is in the application or subsystem, examine the statistics
exception report for unusual conditions, such as buffer pool thresholds
experienced, to determine the cause. You should also examine the lockout trace
for timeouts and deadlocks.
High Class 1 Elapsed Time: If you suspect an application problem, examine the
accounting report for the reported times. If the exception thresholds have been
set to monitor class 1 elapsed times for critical transactions, the exception report
gives the time and severity of the problem and indicates how far the exception
has exceeded its threshold.
You may want to consider producing the accounting report that shows individual
invocations of a plan. However, restrict the period of reporting to that given
around the time indicated in the exception report as significantly more
information is produced with this type of report. Compare class 1 elapsed time
with class 2 elapsed time.
Low Class 2 Elapsed Time: If most of the elapsed time spent is in class 1 and
proportionately little time in class 2, this suggests (see Figure 46 on page 92).
that the problem is not in DB2 and therefore is not DB2 I/O or lock related.
Network and Transaction Manager Reports: High class 1 and low class 2
elapsed times also suggest either a problem in the application logic, forcing it to
do unnecessary processing, a problem with the transaction manager, CICS or
IMS, or a problem in the network. Therefore in this situation use monitors that
examine the relative performance of the transaction manager or network and, if

you suspect a problem with the application, involve the application programmer.
Be aware, however, that for IMS-WFI transactions and CICS transactions using
protected threads, the same thread can be reused by multiple transactions.
Should there be a delay in the arrival of the next transaction, the thread is
terminated. Accounting data is written only when the thread is terminated or
reused, provided that TOKENI is specified as YES in the TYPE=INIT macro
and/or TOKENE is specified as YES in the TYPE=ENTRY macro in the CICS RCT
table. Therefore, in this situation where there is delay in the arrival of the next
transaction, the class 1 elapsed time can give a false impression of a problem as
it may reflect the delay until the next signon, resignon, or thread termination.
Note: To get an idea of the relative processor utilization, compare the ratio of
class 1 CPU time to class 1 elapsed time and the ratio of class 2 CPU time to
class 2 elapsed time.

GROUP: N/P ACCOUNTING REPORT - LONG REQUESTED FROM: NOT SPECIFIED
DB2 VERSION: V4 TO: 04/19/95 15:30:48.06
PRIMAUTH: DB2RES2 PLANNAME: URSM1NG0
AVERAGE APPL (CLASS 1) DB2 (CLASS 2) IFI (CLASS 5) CLASS 3 SUSP. AVERAGE TIME AV.EVENT HIGHLIGHTS
------------ -------------- -------------- -------------- -------------- ------------ -------- --------------------------
ELAPSED TIME 6:32.903638 20.423430 N/P LOCK/LATCH 0.741212 86.00 #OCCURRENCES : 3
CPU TIME 36.412247 13.465832 N/P SYNCHRON. I/O 0.000000 0.00 #ALLIEDS : 3
TCB 36.412247 13.465832 N/P OTHER READ I/O 0.477047 3.67 #ALLIEDS DISTRIB: 0
TCB-STPROC 0.000000 0.000000 N/A OTHER WRTE I/O 1.557551 8.67 #DBATS : 0
CPU-PARALL 0.000000 0.000000 N/A SER.TASK SWTCH 3.159054 12.00 #DBATS DISTRIB. : 0
NOT ACCOUNT. N/A 1.022734 N/A ARC.LOG(QUIES) 0.000000 0.00 #NO PROGRAM DATA: 0
DB2 ENT/EXIT N/A 24623.00 N/A ARC.LOG READ 0.000000 0.00 #NORMAL TERMINAT: 3
EN/EX-STPROC N/A 0.00 N/A DRAIN LOCK 0.000000 0.00 #ABNORMAL TERMIN: 0
CLAIM RELEASE 0.000000 0.00 #CPU PARALLELISM: 0
DCAPT.DESCR. N/A N/A N/P PAGE LATCH 0.000000 0.00 #IO PARALLELISM : 0
LOG EXTRACT. N/A N/A N/P STORED PROC. 0.000000 0.00 #INCREMENT. BIND: 0
NOTIFY MSGS. 0.000000 0.00 #COMMITS : 3
NOT NULL 3 3 0 GLOBAL CONT. 0.000000 0.00 #ROLLBACKS : 0
TOTAL CLASS 3 5.934865 110.33 UPDATE/COMMIT : 0.00
Figure 46. High Class 1 and Low Class 2 Elapsed Times
High Class 2 TCB Time: High Class 2 TCB time indicates that DB2 is doing a lot
of processing. Figure 47 on page 93 shows an example of high class 2 TCB
time.
92 DB2 PM
DB2 VERSION: V4 TO: 04/19/95 15:30:48.06
------------ -------------- -------------- -------------- -------------- ------------ -------- --------------------------
ELAPSED TIME 2:32.903638 2:20.423430 N/P LOCK/LATCH 0.741212 86.00 #OCCURRENCES : 3
CPU TIME 2:16.412247 2:13.465832 N/P SYNCHRON. I/O 0.000000 0.00 #ALLIEDS : 3
TCB 2:16.412247 2:13.465832 N/P OTHER READ I/O 0.477047 3.67 #ALLIEDS DISTRIB: 0
Figure 47. High Class 2 Elapsed and TCB Times
High SQL Activity: You may suspect a high amount of SQL activity. This can be
reflected by the fact that the application′s processing of getpages may be far
higher than anticipated.
Explain: Run batch explain at the plan level to get the details of the access path
chosen by DB2. Compare the access path generated by explain with the
expected access path specified in your design guidelines. Possible causes of
access path change can be the removal or disqualification of an index. Defining
a host variable with a length that does not match that specified in
SYSIBM.SYSCOLUMNS for that variable disqualifies indexes and is a difficult
problem to trace.
Frequent rebinding of plans due to the execution of RUNSTATS in production

environments where data volumes grow rapidly can affect access path decisions,
and with that the disorganization of data also has a detrimental effect on access
path choice. Figure 48 shows an example of the presentation of explain
information.

GROUP: N/P EXPLAIN PLAN REQUESTED FROM: NOT SPECIFIED
SUBSYSTEM: DB2F ACTUAL FROM: 04/20/95 03:28:52.13
DB2 VERSION: V4
.
.
.
.
|------------------------------------------------|
| Table space scan - no index will be used |
| Standard sequential prefetch will be performed |
| Lock mode is exclusive lock for the page |
| Page range scan will not be used |
|------------------------------------------------|
.
.
.
.
Figure 48. Explain Plan Report Extract

SQL Activity Report: To pinpoint where the class 2 TCB time is being spent, you
can run an SQL activity report. This report produces a great deal of information
and shows events at a very detailed level. Trace records for this report are not
collected by default as the overhead of producing these records is considered
high. You therefore cannot generate retrospective reports. Plan to either
recreate the problem event by rerunning the transaction, something that does
not always produce the desired result because workloads and environmental
conditions change, or arrange to capture the records when the class 2 TCB time
threshold has been exceeded once more.
Use the Collect Report Data function, configured from the DB2 PM Online
Monitor, to automatically turn on the correct traces, following an exception
threshold condition detected for the transaction. The function also automatically
deactivates the traces once a condition has been met, for example, thread
termination, or after the collection of a predefined number of records.
After you have collected the relevant data, run the SQL activity report to
determine the processing activity for each SQL statement. Figure 49 shows an
example of an SQL trace summarized by cursor name and sorted by TCB time
with workload highlights.

GROUP: N/P SQL ACTIVITY - TRACE REQUESTED FROM: NOT SPECIFIED
DB2 VERSION: V4
SUMMARIZED BY CURSOR, SORTED BY TCBTIME, WITH HILITE WORKLOAD
PRIMAUTH: DB2RES2 CONNECT : BATCH CORRNAME: DB2RES2F CONNTYPE: TSO

ORIGAUTH: DB2RES2 PLANNAME: LOCCURHL CORRNAME: ¢BLANK¢ THRDTYPE: ALLIED
TRACE # 1.1 DB2 LUWID: STLNET.STLDB2F.X¢A44FECDC9ED4¢ ACE ADDRESS: X¢02684398¢
START TIME: 04/20/95 03:28:52.13 START ELAPSED: 0.087542 START REASON: CREATE THREAD
STOP TIME : 04/20/95 03:29:02.63 STOP ELAPSED : 0.009044 STOP REASON : TERMINATE THREAD
EVENT COUNT AET/EVENT TCB/EVENT DETAIL

-------------------- ----------- ----------- --------- -----------------------------------------------------------------------------
C2NOHOLD 3 2.617735 0.009841 DBRM: LOCCURHL
STMTTYPE COUNT AET/OCCUR TCB/OCCUR COMMITS: 4
UPDATE 1 0.230461 0.004741
OPEN 3 0.001238 0.000251
FETCH 3 1.001623 0.002264
DELETE 1 4.614161 0.017236
------------------------------------------------------------------------------------------------------------------------------------
WORKLOAD HILITE SCANS : 10 RECS/SORT: N/P I/O REQS: 12 SUSPENDS: N/P EXITS : 6 AMS : N/P
DATACAPTURE: YES ROWSPROC: 9 WORK/SORT: N/P AET/I/O : 0.027392 AET/SUSP: N/P AET/EXIT: 0.001787 AET/AMS : N/P
RIDS UNUSED: N/P PAGESCAN: 22 PASS/SORT: N/P QUERY PARALLELISM PLANNED/NEGOTIATED DIFFERENCE : N/P CHECKCON: N/P
C1HOLD 1 1.187397 0.009101 DBRM: LOCCURHL

STMTTYPE COUNT AET/OCCUR TCB/OCCUR COMMITS: 4
UPDATE 2 0.466585 0.002298
OPEN 1 0.000208 0.000207
FETCH 4 0.063392 0.000962
CLOSE 1 0.000451 0.000451
------------------------------------------------------------------------------------------------------------------------------------
WORKLOAD HILITE SCANS : 15 RECS/SORT: 1.00 I/O REQS: 2 SUSPENDS: 1 EXITS : N/P AMS : N/P
DATACAPTURE: YES ROWSPROC: 18 WORK/SORT: 3.00 AET/I/O : 0.018509 AET/SUSP: 0.000752 AET/EXIT: N/P AET/AMS : N/P
RIDS UNUSED: N/P PAGESCAN: 24 PASS/SORT: 1.00 QUERY PARALLELISM PLANNED/NEGOTIATED DIFFERENCE : 0 CHECKCON: N/P
# 245 1 1.137912 0.007616 INSERT ISO N/A

DBRM: LOCCURHL
------------------------------------------------------------------------------------------------------------------------------------
WORKLOAD HILITE SCANS : 4 RECS/SORT: N/P I/O REQS: 2 SUSPENDS: N/P EXITS : 1 AMS : N/P
DATACAPTURE: N/P ROWSPROC: 2 WORK/SORT: N/P AET/I/O : 0.028165 AET/SUSP: N/P AET/EXIT: 0.000060 AET/AMS : N/P
RIDS UNUSED: N/P PAGESCAN: 11 PASS/SORT: N/P QUERY PARALLELISM PLANNED/NEGOTIATED DIFFERENCE : N/P CHECKCON: N/P
Figure 49. SQL Activity Trace Summarized by Cursor
94 DB2 PM
The average TCB time for each statement occurrence executed under the cursor
name is shown, as well as for the cursor as a whole. Here the highest user in
terms of cursor, of CPU class 2 TCB time, is displayed first.
High Class 3 Wait Time: If class 2 TCB time is not high, check whether class 3
wait time is high.
Not Accounted: If class 2 elapsed time is high but class 2 TCB time and class 3
wait time are low, examine the NOT ACCOUNT. field in the accounting report
(see Figure 50).

DB2 VERSION: V4 TO: 04/19/95 15:30:48.06
------------ -------------- -------------- -------------- -------------- ------------ -------- --------------------------
ELAPSED TIME 2:02.835677 1:20.423430 N/P LOCK/LATCH 0.741212 86.00 #OCCURRENCES : 3
NOT ACCOUNT. N/A 1:01.022734 N/A ARC.LOG(QUIES) 0.000000 0.00 #NO PROGRAM DATA: 0
Figure 50. High NOT ACCOUNTED Time
RMF Report: A high value for the NOT ACCOUNT. field indicates that wait time
is not occurring in DB2. The high value may be because of incorrect dispatching
priority for the transaction, causing wait time before the system resource
manager (SRM) dispatches the task to the CPU, or MVS paging activity.
Examination of the MVS RMF report provides a means of identifying the cause of
the not accounted time.
High Lock/Latch Time: Probably the most common cause of high overall
elapsed time is high class 3 time. Class 3 time reports suspensions in a variety
of areas, but more interestingly in the locking/latching and I/O areas. Figure 51
on page 96 shows an example of the high class 3 lock/latch time.

DB2 VERSION: V4 TO: 04/19/95 15:30:48.06
PRIMAUTH: DB2RES2 PLANNAME: URSUELI
------------ -------------- -------------- -------------- -------------- ------------ -------- --------------------------
ELAPSED TIME 4:13.235677 3.20.423430 N/P LOCK/LATCH 3.00.741212 86.00 #OCCURRENCES : 3
TOTAL CLASS 3 3.05.934864 110.33 UPDATE/COMMIT : 0.00
Figure 51. High Class 3 Lock/Latch Time
When considering locking problems, if there have been an unusually high

number of lock suspensions, check that the plan has not been bound with
repeatable read. Repeatable read maintains S-locks on pages containing rows
accessed during a unit of work. These locks prevent updates, deletes, and
inserts by other processes until commit point is reached and can therefore hold
locks for an undesirable length of time. Locking problems invariably lead to the
necessity to produce a locking report.
Can Recreate the Problem Now?: Examine whether you can recreate the
problem that leads to high class 3 lock/latch time.
Collect Trace into UDS: If deadlocks and timeouts are not the cause of large
lock suspension times, consider the lock suspension report (see Figure 52 on
page 97).
The input records required for the lock suspension report are not collected by
default. You will need to plan for their collection. Use the Collect Report Data
function to start the correct traces and gather the trace records to the collect
task data set. The benefit of writing the trace records to a separate data set
from SMF or GTF is that the data is immediately available for use.
If the problem transaction can be rerun and produces the same high lock
suspensions, consider starting the Collect Report Data task immediately and
rerunning the transaction. Refer to the IBM DATABASE 2 Performance Monitor
for MVS (DB2 PM) Version 4 Batch User ′ s Guide , Chapter 3, “Collecting
Performance Data” for a detailed explanation of how to configure a collect task.
Trigger Trace Data Collection by Exception: If you cannot easily recreate the
problem that leads to high class 3 lock/latch time, you can decide to trigger the
collection of data by an exception condition. Consider defining a new exception
threshold data set with a single entry qualifying the plan name and setting a
value considered an exception for the class 3 lock and latch suspension time.
You must now activate periodic exception processing, described in 3.2,
“Activating the Exception Processor” on page 38, specifying your new exception
threshold data set on the Exception Processor panel. If you are running an
active data collector, you can log off the system. When an exception is raised,
96 DB2 PM
automatic trace collection begins. Installations that do not run the data collector
can enable trace data collection by exception triggering, but the userid that
activated periodic monitoring must remain logged on and within the DB2 PM
Online Monitor.
Lock Suspension Report: The lock suspension report indicates the type of
suspension and the DB2 object on which the suspension occurred. Figure 52
shows the lock suspension report.

GROUP: N/P LOCKING REPORT - SUSPENSION REQUESTED FROM: NOT SPECIFIED
DB2 VERSION: V4 SCOPE: MEMBER TO: 04/20/95 11:00:13.13
--SUSPEND REASONS-- ---------- R E S U M E R E A S O N S -----------

PRIMAUTH --- L O C K R E S O U R C E --- TOTAL LOCAL GLOB. S.NFY ---- NORMAL ---- TIMEOUT/CANCEL --- DEADLOCK ---
PLANNAME TYPE NAME SUSPENDS LATCH IRMLQ OTHER NMBR AET NMBR AET NMBR AET
------------------ --------- ----------------------- -------- ----- ----- ----- ---- ----------- ---- ----------- ---- -----------
DB2PMF
DB2PM410 N/P N/P 40 0 0 0 40 0.000457 0 N/C 0 N/C
0 40 0
DB2RES2
DSNESPRR PAGESET DB =DSNDB04 1 1 0 0 1 5.439679 0 N/C 0 N/C
OB =COLBABY2 0 0 0
DB2RES3
DSNESPCS PAGESET DB =DSNDB04 1 1 0 0 0 N/C 0 N/C 1 7.736040
OB =COLBABY 0 0 0
*GRAND TOTAL* 42 2 0 0 41 0.133121 0 N/C 1 7.736040
0 40 0
Figure 52. Lock Suspension Report
High I/O Suspension Time: If the perceived problem is high class 3 I/O
suspension time, the following factors can contribute to the symptom:
Unexpected Prefetch: For transaction-based applications an unexpected

prefetch may mean that many more getpages are being performed, potentially
resulting in increased CPU and positively increased I/O. Examine the getpage
field of the accounting report and estimate whether the number of reported
getpages map to your expectations. High-volume, short-elapsed-time
transactions typically use index access to retrieve the data, with a resultant
small number of getpages. For high-volume transactions certainly the index
pages should be found in the buffer pool for a high percentage of the time. The
number of index pages found in the buffer pool depends on the size of the buffer
pool and the size of the index. The common assumption is that the root pages
and 50% of the nonleaf pages are in the buffer pool, and none of the leaf pages
is in the buffer pool.
To determine the buffer pool hit ratio use the following formula:
PREFETCH-PAGES = (PAGES READ-SEQ.PREF. +

PAGES READ-LST.PREF. +
PAGES READ-DYN.PREF.)
BUFFER HIT RATIO = (GETPAGES-SEQ&RANDOM -

SYNC.READ-SEQ&RANDOM -
PREFETCH-PAGES) /
GETPAGES-SEQ&RANDOM
Use Figure 54 on page 101 as a reference for these fields.

Access Path Change: Explain: To determine whether there is a change in the
access path, examine the DB2 PM batch explain report.
Unexpected Synchronous I/O: For applications relying on prefetch, for example,

MIS query environments, a high I/O suspension time can indicate that either
prefetch is being disabled because the sequential prefetch threshold is being
reached or prefetched pages already in the buffer pool are being stolen before
the getpage request is issued. These getpages are subsequently read
synchronously, hence the high I/O suspensions. This problem indicates that the
buffer pool requires tuning.
Sequential Prefetch Disabled: Look at the statistics report and check for a high
value in the PREF. DISABLED NO BUFFER field. This problem indicates that the
buffer pool requires tuning.
Failures in RID List processing can also cause high unsuspected I/O suspensions
as the application reverts to a table space scan when index access was
expected. This situation is caused when the number of RID entries is greater
than the maximum limit of 25% of the table size or because the number of RID
entries that can fit into the guaranteed number of RID blocks (4000) was
exceeded. To determine whether a transaction uses the RID pool, see the RID
Pool Processing section of the DB2 PM accounting trace or report.
Access Path Change: Explain: To determine whether there is a change in the

access path, examine the DB2 PM batch explain report.
Statistics Report: I/O suspensions can occur because of disorganized data or

bad data placement. Try to separate physical data placement for table spaces
and indexes accessed by the same application and fence partitioned table
spaces and indexes from each other. Explicit placement of data can be achieved
by a number of methods. By using DB2 storage groups or user-defined DB2
objects (VCAT defined) you can map table spaces and indexes to specific DASD
volumes. DFSMS can also be used to separate DB2 objects at the table space
and index level, or at a more specific level. This may require the activities of a
storage specialist in designing specific SMS automatic class selection (ACS)
routines for indexes and table spaces. Parallelism, if it can be enabled, can
provide a remedy for this problem.
RMF Report: If you suspect that the problem is related to data placement, you
can obtain additional information regarding the performance of DASD volumes
by running the RMF report.
Although not as frequent as an I/O suspension or a lock suspension, a service

task suspension sometimes is significant. The most important factors, in order of
priority, that contribute to a service task suspension are:
1. Preformatting in insert and for sort work files
2. SYSLGRNG(DB2 V3) or SYSLGRNX(DB2 V4) in physical or pseudo open/close
3. Data set open/close
4. Data set extend.
Timeouts and Deadlocks: If the application problem is caused by timeouts and

deadlocks, try to reduce them to an absolute minimum because they can be
critical issues for your business. For example, businesses querying customers
98 DB2 PM
by phone are particularly sensitive to deadlocks as customers may take their
business elsewhere if they have to wait while deadlocks are resolved.
Lockout Trace or Report: Generate a deadlock trace regularly and a lockout

trace or report when needed. These will help detect the timeout and deadlock
problems quickly. The lockout trace shows the holders and waiters of the
resource and identifies the resource at the center of the contention (see
Figure 53).
You can also view the timeouts and deadlocks from the Data Collector Event
Exceptions panel of the DB2 PM Online Monitor.
***********************************************
GROUP: N/P LOCKING TRACE - LOCKOUT REQUESTED FROM: NOT SPECIFIED
DB2 VERSION: V4 SCOPE: MEMBER PAGE DATE: 04/19/95
PRIMAUTH CORRNAME CONNTYPE
ORIGAUTH CORRNMBR INSTANCE EVENT TIMESTAMP --- L O C K R E S O U R C E ---
PLANNAME CONNECT RELATED TIMESTAMP EVENT TYPE NAME EVENT SPECIFIC DATA
------------------------------ ----------------- -------- --------- ----------------------- ----------------------------------------
DB2RES3 DB2RES3 TSO 10:10:13.35291506 DEADLOCK COUNTER = 2 WAITERS = 2
DB2RES3 ¢BLANK¢ AAF2DD62C95E N/P TSTAMP =04/20/95 10:10:13.33
DSNESPRR TSO PAGESET DB =DSNDB04 HASH =X¢000001E0¢
OB =COLBABY ---------------- HOLDER ----------------
LUW=.USIBMSST11
MEMBER =N/P CONNECT =TSO
PLANNAME=DSNESPRR CORRNAME=DB2RES2
DURATION=COMMIT CORRNMBR=¢BLANK¢
STATE =X RESULTANT STATE
NONRESTART MODIFY NONPRIVATE
---------------- WAITER ----------------
LUW=.USIBMSST11
REQUEST =LOCK WORTH = 17
STATE =S RESULTANT STATE
UNCONDITIONAL NONRESTART NONMODIFY
NOFORCE NONPRIVATE SINGLE-UNLK ACQUIRE
PAGESET DB =DSNDB04 HASH =X¢00000140¢

OB =14 ---------------- HOLDER ----------------
LUW=.USIBMSST11
---------------- WAITER ----------------
LUW=.USIBMSST11
Figure 53. Lockout Trace
High insert applications using indexes with a subpage value greater than 1 could
cause a deadlock. There is a high rate of subpage splitting, and the resultant
lock escalation at the index page and nonleaf page level increases the chances
of deadlocks. Reducing the subpage parameter to 1 can help eliminate
deadlocks.
Installations using DB2 Version 4 and utilizing type 2 indexes have no subpage
splitting problem because there is no subpage with type 2 indexes.

A suspension is a wait for a lock. It ultimately results in normal resumption,
timeout, or deadlock. You should expect timeouts to occur, but plan to monitor
their occurrence on critical systems by setting exception thresholds based on the
acceptable number of timeouts that the application can support. Typical causes
of timeouts are applications holding locks for unnecessarily long periods (for
example, through use of repeatable read). Lock escalations and serialization
problems can also cause timeouts. Development environments running a large
number of binds can experience a high number of timeouts on the DB2 catalog
tables. To resolve this problem enforce the running of bind operations through
the use of a unique job name.
SQL Activity Report: Deadlocks can also occur when different application plans
access the same objects but in a different sequence. This naturally is a difficult
problem to solve; however, by using the SQL activity report you can
chronologically identify each SQL statement issued and thereby identify the
objects accessed. Comparing the results of the sequence of access by the two
transactions can prove or disprove your suspicion.
DB2 Subsystem Problem: If you suspect that the problem is not in the
application, you should investigate whether it is a DB2 subsystem problem.
Examine Statistics Report: To investigate a DB2 subsystem problem, examine

the statistics report.
Figure 54 on page 101 shows an example of a statistics report. For a guideline

on the critical fields to check, refer to Table 2 on page 46 and Table 3 on
page 48. Values outside the thresholds given in those tables should be
investigated as a starting point in your problem determination. For some
problems, such as EDM Pool Full, temporary measures such as stopping and
starting databases may relieve critical situations. For other problems, such as
resizing the EDM Pool, it may be necessary to stop and start DB2.
100 DB2 PM
GROUP: N/P STATISTICS REPORT - SHORT REQUESTED FROM: NOT SPECIFIED
SUBSYSTEM: DB2F INTERVAL FROM: 04/25/95 17:45:05.66
---- HIGHLIGHTS -------------------------------------------------------------------------------------------------------------------

INTERVAL START: 04/25/95 17:45:05.66 INTERVAL ELAPSED: 14:11:40.62 INCREMENTAL BINDS : 0.00 DBAT QUEUED: N/P
INTERVAL END : 04/26/95 07:56:46.28 OUTAGE ELAPSED : 0.000000 AUTH SUCC.W/OUT CATALOG: 24.00 DB2 COMMAND: 7.00
SAMPLING START: 04/25/95 17:45:05.66 TOTAL THREADS : 27.00 BUFF.UPDT/PAGES WRITTEN: 34.61 TOTAL API : 12982.00
SAMPLING END : 04/26/95 07:56:46.28 TOTAL COMMITS : 351.00 PAGES WRITTEN/WRITE I/O: 22.51 MEMBER : N/A
CPU TIMES TCB TIME SRB TIME TOTAL TIME OPEN/CLOSE ACTIVITY QUANTITY
------------------------------- --------------- --------------- --------------- ------------------------- --------
SYSTEM SERVICES ADDRESS SPACE 38.041327 9.039923 47.081250 OPEN DATASETS - HWM 55.00
DATABASE SERVICES ADDRESS SPACE 1.527453 24.399592 25.927045 OPEN DATASETS 53.11
IRLM 0.046277 10.322403 10.368680 IN USE DATA SETS 1.97
DDF ADDRESS SPACE 0.718559 0.140787 0.859346 SUCCESSFUL LOGICAL REOPEN 595.00
NON-CPU TIME N/A N/A 14:10:16.384986
SQL DML QUANTITY SQL DCL QUANTITY SQL DDL QUANTITY LOCKING ACTIVITY QUANTITY DATA SHARING LOCKS QUANTITY
-------- -------- -------------- -------- ---------- -------- ---------------- -------- ------------------ --------
SELECT 240.00 LOCK TABLE 0.00 CREATES 5.00 DEADLOCKS 0.00 LOCK REQ.(P-LOCK) 0.00
INSERT 2.00 GRANT 0.00 DROPS 0.00 TIMEOUTS 1.00 UNLOCK REQ.(P-LCK) 0.00
UPDATE 14.00 REVOKE 0.00 ALTERS 0.00 SUSPENSIONS-LOCK 1.00 CHANGE REQ.(P-LCK) 0.00
DELETE 0.00 SET HOST VAR. 0.00 COMMENT ON 0.00 SUSPENSIONS-OTHR 33543.00 SYNC.XES - LOCK 0.00
PREPARE 46.00 SET SQLID 0.00 LABEL ON 0.00 LOCK REQUESTS 5480.00 SYNC.XES - CHANGE 0.00
DESCRIBE 7.00 SET DEGREE 0.00 TOTAL 5.00 UNLOCK REQUEST 12951.00 SYNC.XES - UNLOCK 0.00
DESC.TBL 0.00 SET RULES 0.00 LOCK ESCALAT(SH) 0.00 ASYN.XES-RESOURCES 0.00
OPEN 62.00 CONNECT TYPE 1 0.00 LOCK ESCALAT(EX) 2.00 TOTAL SUSPENDS 0.00
CLOSE 62.00 CONNECT TYPE 2 0.00 DRAIN REQUESTS 39.00 P-LCK/NFY ENG.UNAV 0.00
FETCH 21816.00 RELEASE 0.00 CLAIM REQUESTS 810.00 INCOM.RETAINED LCK 0.00
TOTAL 22249.00 SET CONNECTION 0.00 PSET/PART NEGOTIAT 0.00
TOTAL 0.00 PAGE NEGOTIATION 0.00
RID LIST QUANTITY STORED PROCEDURES QUANTITY QUERY PARALLELISM QUANTITY PLAN/PACKAGE PROC. QUANTITY
-------------------- -------- ----------------- -------- --------------------- -------- ------------------- --------
MAX BLOCKS ALLOCATED 2.00 CALL STATEMENTS 0.00 MAX DEGREE 0.00 PLAN ALLOC-ATTEMPTS 27.00
CURRENT BLKS ALLOC. 0.00 PROCEDURE ABENDS 0.00 GROUPS EXECUTED 0.00 PLAN ALLOC-SUCCESS 27.00
FAILED-NO STORAGE 0.00 CALL TIMEOUTS 0.00 EXECUTED AS PLANNED 0.00 PACK ALLOC-ATTEMPTS 321.00
FAILED-RDS LIMIT 0.00 CALL REJECTED 0.00 REDUCED DEG-NO BUFFER 0.00 PACK ALLOC-SUCCESS 321.00
FAILED-DM LIMIT 0.00 FALL TO SEQUENTIAL 0.00 AUTOBIND ATTEMPTS 0.00
FAILED-PROCESS LIMIT 0.00 AUTOBIND SUCCESSFUL 0.00
SUBSYSTEM SERVICES QUANTITY LOG ACTIVITY QUANTITY EDM POOL QUANTITY

-------------------------------- -------- --------------------------------- -------- ------------------------- --------
IDENTIFY 17.00 READS SATISFIED-OUTPUT BUFFER 0.00 PAGES IN EDM POOL 1890.00
CREATE THREAD 27.00 READS SATISFIED-ACTIVE LOG 0.00 FREE PAGES IN FREE CHAIN 1849.55
SIGNON 0.00 READS SATISFIED-ARCHIVE LOG 0.00 FAILS DUE TO POOL FULL 0.00
TERMINATE 48.00 READ DELAYED-UNAVAILABLE RESOURCE 0.00 PAGES USED FOR CT 5.65
ROLLBACK 9.00 READ DELAYED-ARCH.ALLOC. LIMIT N/A PAGES USED FOR PT 0.00
COMMIT PHASE 1 0.00 WRITE-NOWAIT 665.6K PAGES USED FOR DBD 14.91
COMMIT PHASE 2 0.00 WRITE OUTPUT LOG BUFFERS 1937.00 PAGES USED FOR SKCT 4.91
READ ONLY COMMIT 0.00 BSDS ACCESS REQUESTS 1180.00 PAGES USED FOR SKPT 14.98
UNITS OF RECOVERY GONE INDOUBT 0.00 UNAVAILABLE OUTPUT LOG BUFFER 215.00 REQUESTS FOR CT SECTIONS 25.00
UNITS OF RECOVERY INDOUBT RESOLV 0.00 CONTROL INTERVAL CREATED-ACTIVE 33249.00 CT NOT IN EDM POOL 1.00
SYNCHS (SINGLE PHASE COMMIT) 342.00 ARCHIVE LOG READ ALLOCATION 0.00 REQUESTS FOR PT SECTIONS 612.00
QUEUED AT CREATE THREAD 0.00 ARCHIVE LOG WRITE ALLOCAT. 8.00 PT NOT IN EDM POOL 2.00
SYSTEM EVENT CHECKPOINT 15.00 REQUESTS FOR DBD SECTIONS 372.00
Figure 54 (Part 1 of 2). Statistics Report

DBD NOT IN EDM POOL 5.00
LOCATION: ST11DB2F DB2 PERFORMANCE MONITOR (V 4) PAGE: 1-2
GROUP: N/P STATISTICS REPORT - SHOR T REQUESTED FROM: NOT SPECIFIED
SUBSYSTEM: DB2F INTERVAL FROM: 04/25/95 17:45:05.66
---- HIGHLIGHTS -------------------------------------------------------------------------------------------------------------------

INTERVAL START: 04/25/95 17:45:05.66 INTERVAL ELAPSED: 14:11:40.62 INCREMENTAL BINDS : 0.00 DBAT QUEUED: N/P
INTERVAL END : 04/26/95 07:56:46.28 OUTAGE ELAPSED : 0.000000 AUTH SUCC.W/OUT CATALOG: 24.00 DB2 COMMAND: 7.00
SAMPLING START: 04/25/95 17:45:05.66 TOTAL THREADS : 27.00 BUFF.UPDT/PAGES WRITTEN: 34.61 TOTAL API : 12982.00
SAMPLING END : 04/26/95 07:56:46.28 TOTAL COMMITS : 351.00 PAGES WRITTEN/WRITE I/O: 22.51 MEMBER : N/A
BP0 GENERAL QUANTITY

-------------------- --------
EXPANSIONS N/A
GETPAGES-SEQ&RANDOM 97808.00
GETPAGES-SEQ.ONLY 94992.00
SYNC.READ-SEQ&RANDOM 116.00
SYNC.READ-SEQ.ONLY 14.00
SEQ.PREFETCH REQ 3073.00
SEQ.PREFETCH READS 2832.00
PAGES READ-SEQ.PREF. 90119.00
LST.PREFETCH REQUEST 145.00
LST.PREFETCH READS 4.00
PAGES READ-LST.PREF. 21.00
DYN.PREFETCH REQUEST 0.00
DYN.PREFETCH READS 0.00
PAGES READ-DYN.PREF. 0.00
BUFFER UPDATES 665.2K
SYNCHRONOUS WRITES 48.00
ASYNCHRONOUS WRITES 806.00
DATA SET OPENS 22.00
HDW THRESHOLD 0.00
VDW THRESHOLD 181.00
DM THRESHOLD 0.00
Figure 54 (Part 2 of 2). Statistics Report
102 DB2 PM
Chapter 5. Scenarios
This chapter shows, through different scenarios, a structured approach to

problem solving using DB2 PM. The scenarios, selected to demonstrate the
many DB2 PM facilities available for use in all types of problem situations, cover:
• Sort problem
• Constrained buffer pool problem
• Class 1 elapsed time problem
• Access path problem
• Locking problem.
The examples and values presented in this chapter were produced on a small
test system and may not be representative of the values you have in your
development and production environments.

5.1 Sort Problem
In this scenario query processing predominates and queries are expected to
take considerably longer than other online, nonquery transactions. The queries,
by their nature, order and sort their results for presentation to the user.
The following DB2 PM facilities are used:

• Periodic exception detection
• Collect report data
• Statistics report.
The query transaction profile has changed on your DB2 system, and you have
noticed a general increase in the elapsed time for standard queries to complete.
To investigate this problem you define a single exception threshold for the
problem queries, using their plan name as a qualification filter. To set a
threshold value for the exception you consult an accounting TOP report, where
up to a maximum of 50 top resource users are identified at the end of the report
along with the value being measured. As an alternative you can use an
accounting TOP ONLY report, which shows the accounting information only for
the TOP users of the resource. Figure 55 shows only the TOP list produced at
the end of the accounting report.
DB2 PERFORMANCE MONITOR (V4)

ACCOUNTING REPORT - SHORT
ORDER: PLANNAME
DB2 VERSION: V4
PLANNAME VALUE PAGE

---- ------------------------- --------------- ----------
1 DB2RES23 9:24.061455 1-17
2 DB2RES22 8:32.678890 1-25
3 DB2RES27 3:24.819584 1-05
4 DB2RES21 2:16.955988 1-36
5 DB2RES26 2:09.989897 1-43
6 DB2RES38 2:09.737336 1-21
7 DB2RES34 2:08.898499 1-28
8 DB2RES43 2:08.474778 1-18
9 DB2RES78 2:06.668996 1-13
10 DB2RES89 2:03.434565 1-07
Figure 55. Accounting TOP Report List: Sort Problem
To define an exception threshold for the transaction elapsed time, select option
4, Maintain parameter data sets, from the IBM Database 2 Performance Monitor
panel. You are presented with the Data Set Maintenance Menu. Select option 1,
Maintain exception thresholds. The Exception Threshold Category Selection
panel (see Figure 56 on page 105) is displayed showing accounting and
statistics categories for which you can define exception criteria.
104 DB2 PM
Exception Threshold Category Selection
Command ===> ______________________________________________________________
Select one or more categories, then press Enter. Overtype with space to
deselect any category. Request EXIT when complete.
Category
> Elapsed, CPU and Waiting Times per Plan Execution
_ Elapsed, CPU and Waiting Times per Program Execution
_ CPU Times per Address Space
_ SQL Statements per Plan Execution
_ SQL Statements per Program Execution
_ SQL Statements per System
_ Subsystem Events per Plan Execution
_ Subsystem Events per System
_ Locking Activity per Plan Execution
_ Locking Activity per System
_ RID List Processing per Plan Execution
_ RID List Processing per System
_ Query Parallelism per Plan Execution
_ Query Parallelism per System
_ Buffer Pools Activity per Plan Execution
_ Buffer Pools Activity per System
_ Distributed Activity per Location per Plan Execution
_ Distributed Activity per System
_ Distributed Activity per Location per System
_ IFI and Data Capture Activity per Plan Execution
_ IFI Activity per System
_ EDM Pool Activity per System
_ Open/Close Activity per System
_ Plan/Package Processing per System
_ Log Activity per System
Figure 56. Exception Threshold Category Selection Panel: Sort Problem
After you have selected a category, the Exception Threshold Field Selection
panel (see Figure 57 on page 106) is displayed. It contains fields related to the
category you selected. You can choose any number of entries as exception
fields.
Chapter 5. Scenarios 105

Exception Threshold Field Selection
Command ===> ______________________________________________________________
Select one or more fields, then press Enter. Overtype with space to
deselect any field. Request EXIT when complete.
Field category . . : Elapsed, CPU and Waiting Times per Plan Execution
Field Description
> ADRECETT Elapsed time in application (Class 1)
_ ADTSUST Total Class 3 suspensions time
_ ADCPUT CPU time in application (Class 1)
_ ADTWTAP Total wait time in application (Class 1)
_ ADDB2ETT Elapsed time in DB2 (Class 2)
_ ADDBCPUT CPU time in DB2 (Class 2)
_ ADTWTDB Total wait time in DB2 (Class 2)
_ ADTSUSC Total Class 3 suspensions
_ QWACAWTL Lock/latch suspensions time (Class 3)
_ ADLLSUSC Lock/latch suspensions (Class 3)
_ QWACAWTI Synchronous I/O susp. time (Class 3)
_ ADIOSUSC Synchronous I/O suspensions (Class 3)
_ QWACAWTR Other read I/O susp. time (Class 3)
_ ADARSUSC Other read I/O suspensions (Class 3)
_ QWACAWTW Other write I/O susp. time (Class 3)
_ ADAWSUSC Other write I/O suspensions (Class 3)
_ QWACAWTE Serv.task switch susp. time (Class 3)
_ ADSTSUSC Serv.task swtch suspensions (Class 3)
-- End of Items --
Figure 57. Exception Threshold Field Selection Panel: Sort Problem
After you select elapsed time in application (Class 1) as an exception field, from
the Exception Threshold Field Details panel shown in Figure 58 on page 107,
specify the warning and problem threshold exceptions. These threshold values
are measured in seconds.
106 DB2 PM
Command ===> ______________________________________________________
ENTRY 1 OF 1

Field ID . . . . . : ADRECETT
Description . . . . : Elapsed time in application (Class 1)
Active . . . . . . . . . . . . . 1 1=Yes 2=No

4=Commit 5=Thread

Warning threshold . . . . . . . . 350
Problem threshold . . . . . . . . 500
Local location . . . . . . . . . *
Group name . . . . . . . . . . . *
Member name . . . . . . . . . . . *
Subsystem ID . . . . . . . . . . *
Requester location . . . . . . . *
Connect . . . . . . . . . . . . . *
Planname . . . . . . . . . . . . DSNTEP41
Figure 58. Exception Threshold Field Details Panel: Sort Problem
Select option 5, Control Exception Processing, from the DB2 PM Online Monitor
Main Menu to get to the Exception Processor panel. Invoke periodic exception
processing by selecting Periodic from the Exception Processor panel (see
Figure 59 on page 108). As the problem queries are taking in excess of 1
minute, the periodic unit is set to seconds and the periodic interval, to 30. When
you press Enter, periodic exception processing is enabled.
Note: It is quite possible that a threshold data set used for general periodic
monitoring would have already detected that a problem with sort had occurred.
(The field to define in the DB2 PM threshold data set is MERGE PASS
DEGRADED-LOW BUFFER.)
The exception threshold data set DB2RES2.THRESH1 specified on the Exception

Processor panel contains the exception values defined in Figure 58.

Exception Processor ST11DB2F DB2F
Command ===> ____________________________________________________________

s Periodic
Options
2=Minutes
1-120 Minutes
> Log file data set output needed
DPMOUT data set output needed

Name . . . . . . . . . ¢DB2RES2.THRESH1¢
Figure 59. Exception Processor Panel: Sort Problem
During the course of the next 45 minutes a number of query transactions

meeting the qualifying plan name and exceeding the threshold set by you are
identified.
Note: Provided that the data collector is active, if you are not in DB2 PM at the
time of the exception you will be notified by a TSO Exception Notification
message. If you are not in TSO, you will get an exception notification message
the next time that you log on.
From any of the DB2 PM Online Monitor panels except the LOOK-related panels,
issue the LOOK command to obtain more information on the exceptions. The
Look Selections menu is displayed (see Figure 60 on page 109).
108 DB2 PM
Look Selections
__ 1. Periodic Exceptions
Command ===> ________________________________________________________

Figure 60. Look Selections Menu: Sort Problem
Select option 1, Periodic Exceptions, and press Enter. The Periodic Exceptions
List window is displayed. The Periodic Exceptions List window (see Figure 61)
lists the exceptions that have occurred and information concerning the threshold
values.
Look Selections
-----------------------------------------------------------------------------
| Command ===> ______________________________________________________________ |
| |
| |
| Last Interval . . . . . . . . . . . . . : 95/05/10 13:19:04.23 |
| |
| Descr |
| -------- ------------------ -------- ------------ -------- ---------- |
| _ 12:25:01 ST11DB2F ¢BLANK¢ DB2F ¢BLANK¢ DB2RES23 |
| |
| _ 12:26:01 ST11DB2F ¢BLANK¢ DB2F ¢BLANK¢ DB2RES23 |
| |
| ***************************** BOTTOM OF DATA ****************************** |
-----------------------------------------------------------------------------
Figure 61. Periodic Exceptions List Window: Sort Problem
You need to gather more information to help you with the problem diagnosis. To
collect DB2 performance data for this job use the Collect Report Data function of
the DB2 PM Online Monitor. Select Option 6, Collect Report Data, from the DB2
PM Online Monitor Main Menu. On the Collect Report Data panel enter option 1

to configure a task (see Figure 62 on page 110). Give the task a meaningful
name for easy recognition.
Collect Report Data

Command ===> ___________________________________________________________
ST11DB2F DB2F V4
For any trace task enter one of the following actions:
1=Configure
2=Start
3=Display
4=Stop
Task Description Status

1 Query problem Not yet started
_ Collect task B Never Configured
_ Collect task C Never Configured
_ Collect task D Never Configured
Figure 62. Collect Report Data Panel: Sort Problem
Press Enter. The Trace Configuration window (see Figure 63) is displayed. Set a
trigger to start the collection of data. Because query transactions are currently
active on the system, you can choose the Immediate Start trigger to begin
collection immediately. Select the DB2 PM reports of interest to you. The panel
is scrollable and presents more options for selection. You can qualify the data
being collected by a number of filters and choose plan name and auth ID. These
selections reduce the amount of data written to the data set.
Collect Report Data

-----------------------------------------------------------------------
| Trace Configuration |
|Command ===> __________________________________________________________|
| |
|Task Description . . . . . . : Query problem |
| More: +|
|Trigger by . . . . . . . . . . 4 1=Time |
| 2=Periodic exception |
| 3=Exception event |
| 4=Immediate Start |
| |
|Enter one or more selection characters to start DB2 traces for specific|
|DB2 PM report sets or overtype with a blank to delete the selection. |
| |
| > Accounting |
| _ Audit |
| _ I/O Activity |
| _ Locking |
| _ Record Trace |
| _ SQL Activity |
| |
| |
| |
-----------------------------------------------------------------------
Figure 63. Trace Configuration Window: Sort Problem
110 DB2 PM
Press Enter. You are presented with the Trigger Immediately window (see
Figure 64 on page 111). Specify a data set to contain the data. If you do not
already have this data set defined or want to create a new data set, use option 3
(New) to dynamically define one. Now set the criteria to stop collection of data.
Here you choose to stop collecting data after the trace has been active for a
certain elapsed time. The elapsed time is set to 1800 seconds, and the task is
now ready to be started.
DB2 PM selects and starts the traces for you automatically.

Note: In this particular scenario the transactions causing the problem are
known, so the makeup of the SQL statements are also known. More often the
database administrator cannot specifically identify the transaction or the SQL
that is executing; all that is seen is the resulting problem.
For this scenario, in addition to collecting trace information for accounting and
statistics, collect IFCID 63 (for dynamic or static SQL) to show the SQL statement
being passed and IFCID 95 and IFCID 96 to collect information on the start and
end of a sort. The information will show the number of passes, merge phases,
and the key size and data size. This information is important when calculations
for increasing the sort pool size are to be made.
Collect Report Data

----------------------------------------------------------------------
|----------------------------------------------------------------------|
| Trigger Immediately |
| Command ===> ________________________________________________________|
| |
| Task Description . . . . : Query problem |
| More: + |
| Output Data Set for DB2 trace data to be written to |
| Name . . . . . . . . . . ¢DB2RES2.QUERY.PROBLEM¢ |
| Disposition . . . . . . 3 1=Append |
| 2=Overwrite |
| 3=New |
| |
| Start the DB2 traces immediately |
| |
| Stop the DB2 traces when any of the following conditions occur |
| > Elapsed time . . . . . . . . . . . . . . . 1800 (seconds) |
| _ Number of records collected . . . . . . . . 0 |
| _ Thread termination |
| _ Number of IFCIDs collected . . . . . . . . 0 |
| For IFCID . . . . . . . . . . . . . . . . . 0 + |
| |
| |
| |
----------------------------------------------------------------------
Figure 64. Trigger Immediately Window: Sort Problem
Using the data collected, you can now produce accounting and statistics reports.
Here accounting and statistics long reports are used to get the maximum amount
of information about the problem (see Figure 65 on page 112).
In the accounting report we show only the blocks and fields on which we want to
focus. The class 1 elapsed time is more than 10 minutes.

ACCOUNTING REPORT - LONG
ORDER: PRIMAUTH-PLANNAME
DB2 VERSION: V4
PRIMAUTH: DB2RES2 PLANNAME: DSNTEP41
AVERAGE APPL (CLASS 1) DB2 (CLASS 2)

------------ -------------- --------------
ELAPSED TIME 10:03.464282 5:37.477136
CPU TIME 5:59.715783 3:37.877579
TCB 5:59.715783 3:37.877579
TCB-STPROC 0.000000 0.000000
CPU-PARALL 0.000000 0.000000
NOT ACCOUNT. N/A 17.955438
DB2 ENT/EXIT N/A 865165.00

-------------- ------------ --------
LOCK/LATCH 0.028713 221.00
SYNCHRON. I/O 34.088706 1094.00
OTHER READ I/O 52.690880 2351.00
OTHER WRTE I/O 14.835820 676.00
TOTAL CLASS 3 1:41.644119 4342.00
Figure 65. Accounting Long Report Extract: Sort Problem
The statistics report shown in Figure 66 on page 113 covers the period during
which the Collect Data Report function was active and shows that during sort
processing 15 MERGE PASS DEGRADED-LOW BUF conditions occurred.
112 DB2 PM
STATISTICS REPORT - SORT
DB2 VERSION: V4
------------------------- --------
BUFFERS ALLOCATED - VPOOL 2000.00
BP1 READ OPERATIONS QUANTITY BP1 WRITE OPERATIONS QUANTITY

--------------------------- -------- --------------------------- --------
GETPAGE REQUEST 460.9k BUFFER UPDATES 465.9k
GETPAGE REQUEST-SEQUENTIAL 445.7k PAGES WRITTEN 224.2k
GETPAGE REQUEST-RANDOM 15202.00 BUFF.UPDATES/PAGES WRITTEN 2.08
SYNCHRONOUS READS 57700.00 SYNCHRONOUS WRITES 0.00
SYNCHRON. READS-SEQUENTIAL 57691.00 ASYNCHRONOUS WRITES 9767.00
SYNCHRON. READS-RANDOM 9.00 PAGES WRITTEN PER WRITE I/O 22.96
GETPAGE PER SYN.READ-RANDOM 1689.01
SEQUENTIAL PREFETCH REQUEST 76234.00
SEQUENTIAL PREFETCH READS 70547.00
PAGES READ VIA SEQ.PREFETCH 233.8k
S.PRF.PAGES READ/S.PRF.READ 3.31
BP1 SORT/MERGE QUANTITY TOT4K SORT/MERGE QUANTITY

--------------------------- -------- --------------------------- --------
MERGE PASSES REQUESTED 30.00 MERGE PASSES REQUESTED 30.00
MERGE PASS DEGRADED-LOW BUF 15.00 MERGE PASS DEGRADED-LOW BUF 15.00
WORKFILE REQ-ALL MERGE PASS 7299.00 WORKFILE REQ-ALL MERGE PASS 7299.00
Figure 66. Statistics Long Report Extract: Sort Problem
A value of 15 for the MERGE PASS DEGRADED-LOW BUF field indicates that the
sort pool size may not be adequate.
To display the current sort pool size you should:

1. Select option 3, Display System Parameters, from the DB2 PM Online
Monitor Main Menu and press Enter. The DB2 System Parameters Detail
panel is displayed.
2. Select the Storage Sizes and Connections block and press Enter. The
Storage Sizes and Connections panel is displayed.
The Storage Sizes and Connections panel (see Figure 67 on page 114) shows a
value of 512,000 for Maximum size of SORT Pool field.

Storage Sizes and Connections
Command ===> ____________________________________________________
Storage Sizes
Maximum size of EDM Pool . . . . . . . . . . . . . : 7,743,488
Maximum size of SORT Pool . . . . . . . . . . . . : 512,000
Maximum size of RID Pool . . . . . . . . . . . . . : 19,251,200
Connections to DB2
Maximum concurrent threads . . . . . . . . . . . . : 70
Maximum TSO . . . . . . . . . . . . . . . . . . . : 40
Maximum batch . . . . . . . . . . . . . . . . . . : 20
Maximum remote . . . . . . . . . . . . . . . . . . : 64
Maximum remote active . . . . . . . . . . . . . . : 64
3990 cache . . . . . . . . . . . . . . . . . . . . : BYPASS

Default index type . . . . . . . . . . . . . . . . : 2
Figure 67. Storage Sizes and Connections Panel: Sort Problem
The sort pool size is too small. The best performance of a sort is achieved when
only one merge pass is needed. To calculate how big the sort pool must be to
get one merge pass, use this formula:
16000 * (12 + sort-key-length + sort-data-length + 4 (if ESA))
For the query in this scenario the sort-key-length is 19, and the sort-data-length
is 329. Applying these numbers to the formula, the new sort pool size is
calculated at 5 MB.
Figure 68 on page 115 and Figure 69 on page 116 show the accounting and
statistics reports for the queries executed after the sort pool size was increased.
114 DB2 PM
DB2 VERSION: V4
PRIMAUTH: DB2RES2 PLANNAME: DSNTEP41

------------ -------------- --------------
ELAPSED TIME 7:27.281181 3:04.232957
CPU TIME 4:39.357570 2:19.140272
TCB 4:39.357570 2:19.140272
TCB-STPROC 0.000000 0.000000
CPU-PARALL 0.000000 0.000000

-------------- ------------ --------
LOCK/LATCH 0.016242 112.00
SYNCHRON. I/O 0.424219 27.00
OTHER READ I/O 20.818146 405.00
OTHER WRTE I/O 1.193782 39.00
TOTAL CLASS 3 22.452389 583.00
Figure 68. Accounting Long Report Extract: Increased Sort Pool Size

STATISTICS REPORT - SORT
DB2 VERSION: V4

------------------------- --------
BUFFERS ALLOCATED - VPOOL 2000.00
BP1 READ OPERATIONS QUANTITY BP1 WRITE OPERATIONS QUANTITY

--------------------------- -------- --------------------------- --------
GETPAGE REQUEST 226.4K BUFFER UPDATES 239.7K
GETPAGE REQUEST-SEQUENTIAL 225.9K PAGES WRITTEN 116.1K
GETPAGE REQUEST-RANDOM 514.00 BUFF.UPDATES/PAGES WRITTEN 2.07
SYNCHRONOUS READS 3042.00 SYNCHRONOUS WRITES 0.00
SYNCHRON. READS-SEQUENTIAL 3041.00 ASYNCHRONOUS WRITES 5578.00
SYNCHRON. READS-RANDOM 1.00 PAGES WRITTEN PER WRITE I/O 20.81
SEQUENTIAL PREFETCH REQUEST 17799.00
SEQUENTIAL PREFETCH READS 17474.00
PAGES READ VIA SEQ.PREFETCH 132.9K
S.PRF.PAGES READ/S.PRF.READ 7.61
BP1 SORT/MERGE QUANTITY TOT4K SORT/MERGE QUANTITY

--------------------------- -------- --------------------------- --------
MERGE PASSES REQUESTED 10.00 MERGE PASSES REQUESTED 10.00
MERGE PASS DEGRADED-LOW BUF 0.00 MERGE PASS DEGRADED-LOW BUF 0.00
WORKFILE REQ-ALL MERGE PASS 170.00 WORKFILE REQ-ALL MERGE PASS 170.00
Figure 69. Statistics Long Report Extract: Increased Sort Pool Size
Comparing the accounting reports (Figure 65 on page 112 and Figure 68 on

page 115), you see that significant savings have been made. The class 1
elapsed time shows a savings of 25%, and the total class 3 suspension time
shows a savings of 78%.
The sort merge activity reported in Figure 69 shows that the number of times
that a merge pass was not efficiently performed due to a shortage of space in
the buffer pool was zero. This reflects healthy sort activity.
116 DB2 PM
5.2 Constrained Buffer Pool Problem
This scenario demonstrates a problem related to query processing and the effect
that small buffer pools can have on application elapsed time. Buffer pool BP1 is
used by DSNDB07 workfiles and therefore its performance is important for query
processing where sort activity is required.
In this section we show how the problem can be identified and explain how DB2
PM functions are used to analyze and provide information necessary for problem
resolution.

• Accounting TOP list
• Diagnose function.
During periodic monitoring, by using the accounting TOP report list, you identify
a number of queries that show a higher than expected class 3 suspension time.
In this environment class 3 suspension time is seen as an effective way of
measuring the performance of query processing, and a profile of the average
expected class 3 suspension time has been derived over a period of time.
Note: You also could have detected the problem by using an accounting
exception report. Typically the report would show a number of different plans
and users experiencing slow response time (class 1 elapsed time).
At the end of the accounting report you see the TOP 10 occurrences of threads
with the highest class 3 suspension time (Figure 70 on page 118). The TOP list
is organized in descending order of problem value and provides page references
where the accounting information can be found. Figure 70 on page 118 and
Figure 71 on page 119 are part of the same accounting report; they are
separated for clarity.

ORDER: PLANNAME
DB2 VERSION: V4
TOP FIELD: TOTAL SUSPENSION TIME TOP NUMBER REQUESTED: 10
PLANNAME VALUE PAGE

---- ------------------------- --------------- ----------
1 DB2RES22 5:32.291300 1-25
2 DB2RES26 3:35.121125 1-17
3 DB2RES27 3:24.819584 1-05
4 DB2RES21 2:44.804853 1-36
5 DB2RES23 2:09.989897 1-43
6 DB2RES38 2:09.737336 1-21
7 DB2RES34 2:08.898499 1-28
8 DB2RES43 2:08.474778 1-18
9 DB2RES78 2:06.668996 1-13
10 DB2RES89 2:03.434565 1-07
Figure 70. Accounting TOP Report List: Constrained Buffer Pool Problem
The accounting report shows values as an average of the number of the

occurrences. Of particular interest in this case is the Synchronous Read field.
In general you expect to see limited synchronous reads and virtually all pages
brought into the buffer pool by sequential prefetch or pages reread from the
buffer pool. In this case, however, there were 526 synchronous reads (see
SYN.READ field in Figure 71 on page 119).
118 DB2 PM
DB2 PERFORMANCE MONITOR (V4) PAGE: 1-25
ACCOUNTING REPORT - SHORT REQUESTED FROM: NOT SPECIFIED
TO: NOT SPECIFIED
ORDER: PLANNAME INTERVAL FROM: 05/10/95 20:13:09.38
TO: 05/10/95 20:24:32.71
#OCCURS #ROLLBK SELECTS INSERTS UPDATES

PLANNAME #DISTRS #COMMIT FETCHES OPENS CLOSES
--------------------------- ------- ------- ------- ------- -------
DB2RES21 9 0 0.00 0.00 0.00

0 18 0.00 0.00 0.00
----------------------------------------------------------------
|PROGRAM NAME TYPE #OCCURS SQLSTMT CL7 ELAP.TIME
|DSNTEP2 PACKAGE 9 9.00 3:46.022450
----------------------------------------------------------------
DELETES CLASS1 EL.TIME CLASS2 EL.TIME GETPAGES SYN.READ LOCK SUS

PREPARE CLASS1 CPUTIME CLASS2 CPUTIME BUF.UPDT TOT.PREF #LOCKOUT
------- -------------- -------------- -------- -------- --------
0.00 3:46.114679 3:46.022711 28558.00 526.50 0.00

3.00 58.657429 58.637495 21794.00 4514.00 0
---------------------------------------
CL7 CPU TIME CL8 SUSP.TIME CL8 SUSP|
58.637444 2:44.804853 5228.00|
---------------------------------------
Figure 71. Accounting Short Report Extract: Constrained Buffer Pool Problem
You need more detailed information for this problem thread, so you produce an
accounting long report (see Figure 72 on page 120).
Under class 3 suspension time OTHER READ I/O (prefetch) is the biggest
contributor to the overall class 3 suspension time. The buffer pool hit ratio is a
useful measurement for determining the relative efficiency of the buffer pool as it
is the measure of how often a page access (a getpage) is satisfied without
requiring an I/O. To determine the buffer hit ratio, use this formula:
(GETPAGES - SYNCHRONOUS READ - PAGES READ ASYNCHR)/GETPAGES
Here the buffer hit ratio is calculated to be 0.44. The best possible value is 1.0,
which is achieved when every page is found in the buffer pool. The value 0.44
therefore indicates that the efficiency of BP1 is poor. Buffer pool BP1 needs
tuning.

ORDER: PLANNAME
PLANNAME: DB2RES21

------------ -------------- --------------
ELAPSED TIME 3:46.114679 3:46.022711
CPU TIME 58.657429 58.637495
TCB 58.657429 58.637495
TCB-STPROC 0.000000 0.000000


-------------- ------------ --------
LOCK/LATCH 0.017365 141.00
SYNCHRON. I/O 18.390684 527.00
OTHER READ I/O 2:05.940438 3538.50
OTHER WRTE I/O 16.671805 1010.00
TOTAL CLASS 3 2:44.804853 5228.00
BP0 AVERAGE TOTAL BP1 AVERAGE TOTAL

-------------------------- ------ --------------------------- -----
EXPANSIONS N/A N/A EXPANSIONS N/A N/A
GETPAGES 9418.00 18836 GETPAGES 19140.00 38280
BUFFER UPDATES 2026.00 4052 BUFFER UPDATES 19768.00 39536
SYNCHRONOUS WRITE 1.00 2 SYNCHRONOUS WRITE 0.00 0
SYNCHRONOUS READ 50.50 101 SYNCHRONOUS READ 476.00 952
SEQUENTIAL PREFETC 255.00 510 SEQUENTIAL PREFETCH 4259.00 8518
LIST PREFETCH 0.00 0 LIST PREFETCH 0.00 0
DYNAMIC PREFETCH 0.00 0 DYNAMIC PREFETCH 0.00 0
PAGES READ ASYNCHR 8121.00 16242 PAGES READ ASYNCHR.10131.00 20262
Figure 72. Accounting Long Report Extract: Constrained Buffer Pool Problem
DSNDB07 uses BP1 for workfiles whose maximum prefetch value is 8. This
value, however, can become degraded because of buffer shortage. The value in
the S.PRF.PAGES READ/S.PRF.READ field is 1.92 (see Figure 73 on page 121),
suggesting that the maximum of 8 was severely reduced, and therefore many
more prefetches were needed to process the data.
PAGES WRITTEN PER WRITE I/O is a measure of write efficiency. If the buffer
pool size is small, the deferred write thresholds (the HORIZ.DEF.WRITE
THRESHOLD and VERTI.DEF.WRITE THRESHOLD fields in Figure 73 on page 121)
are frequently reached, causing I/Os to be scheduled more often. Thus the
deferred write queue cannot grow large enough to achieve a high ratio of pages
written per I/O. The value of 3.84 pages written per write I/O is low.
120 DB2 PM
STATISTICS REPORT - LONG
BP1 GENERAL QUANTITY BP1 READ OPERATIONS QUANTITY

---------------------------------- ------------------------------------
CURRENT ACTIVE BUFFERS 4.25 GETPAGE REQUEST 302.4K
UNAVAIL.BUFFER-VPOOL FULL 0.00 GETPAGE REQUEST-SEQUENTIAL 301.7K
GETPAGE REQUEST-RANDOM 676.00
NUMBER OF DATASET OPENS 0.00
SYNCHRONOUS READS 6040.00
BUFFERS ALLOCATED - VPOOL 200.00 SYNCHRON. READS-SEQUENTIAL 6032.00
BUFFERS ALLOCATED - HPOOL 0.00 SYNCHRON. READS-RANDOM 8.00
HPOOL BUFFERS BACKED 0.00
BP1 WRITE OPERATIONS QUANTITY
---------------------------------- SEQUENTIAL PREFETCH REQUEST 82183.00
BUFFER UPDATES 314.0K SEQUENTIAL PREFETCH READS 81576.00
PAGES WRITTEN 169.6K PAGES READ VIA SEQ.PREFETCH 156.5K
BUFF.UPDATES/PAGES WRITTEN 1.85 S.PRF.PAGES READ/S.PRF.READ 1.92
PAGE-INS REQUIRED FOR READ 1.00
SYNCHRONOUS WRITES 0.00
PAGES WRITTEN PER WRITE I/O 3.84
HORIZ.DEF.WRITE THRESHOLD 3289.00

VERTI.DEF.WRITE THRESHOLD 13287.00
DM CRITICAL THRESHOLD 0.00
WRITE ENGINE NOT AVAILABLE 0.00
Figure 73. Statistics Long Report Extract: Constrained Buffer Pool Problem
We rerun the problem query, and on the DB2 PM Online Monitor Thread Detail
panel issue the DIAGNOSE command. The result returned by DIAGNOSE shows
that the buffer pools do have problems in a number of areas (see Figure 74 on
page 122). This information confirms that the buffer pools need tuning. Further
selections from the Diagnosis of Thread window result in more detailed
information and recommendations.

-----------------------------------------------------------------------------.
|-----------------------------------------------------------------------------|
| Command ===> _____________________________________________________________ |
| |
| HISTORY 95/05/11 12:16:52 |
| |
| _ There is evidence of stress on buffer pool BP0 |
| _ The buffer pool read hit ratio for BP0 is low |
| _ Prefetch is not exploited for BP1 |
| _ DASD contention is affecting thread performance |
| |
| _ Actively processing . . . . . . . . . . . . . . . . . . . : 63.55 |
| _ Other read I/O . . . . . . . . . . . . . . . . . . . . . : 10.56 |
| _ Other write I/O . . . . . . . . . . . . . . . . . . . . . : 10.34 |
| _ Synchronous I/O . . . . . . . . . . . . . . . . . . . . . : 10.01 |
| |
| DB2 elapsed time in the current DBRM or package (%) . . . . . : 100.00 |
| |
-----------------------------------------------------------------------------¢
_ SQL Activity, Commits and Rollbacks
DML . . . : 3 Commits . . . . . . . . : 0
DCL . . . : 0 Rollbacks . . . . . . . : 0
DDL . . . : 0 Updates/Commits . . . . : 0.0
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Display Filter View Print Options Help
Figure 74. Diagnosis of Thread Window: Constrained Buffer Pool Problem
On the basis of the evidence collected, one can conclude that the cause of the
poor performance of query processing is undersized buffer pools. Use the
ALTER BUFFERPOOL command to change the buffer pool BP1 size. The buffer
pool sizes are increased and the queries are rerun.
After you have executed the ALTER BUFFERPOOL command and run the query,
the accounting report shows a significant improvement in class 1 elapsed time
and class 3 suspension time. Comparing Figure 75 on page 123 with Figure 72
on page 120, you can see that there is an improvement in the buffer hit ratio,
from 0.44 to 0.90. This improved buffer hit ratio is responsible for the reduction
in the number of read I/Os, and hence the reduction in the class 3 suspension
time.
122 DB2 PM
ORDER: PLANNAME
PLANNAME: DB2RES21

------------ -------------- --------------
ELAPSED TIME 1:48.854413 1:48.766314
CPU TIME 53.041851 53.020952
TCB 53.041851 53.020952

-------------- ------------ --------
LOCK/LATCH 0.051602 113.22
SYNCHRON. I/O 13.727110 111.72
OTHER READ I/O 27.318709 235.89
OTHER WRTE I/O 1.899845 22.78
TOTAL CLASS 3 46.630949 494.22
BP0 AVERAGE TOTAL BP1 AVERAGE TOTAL

-------------------------- ----- --------------------------- -----
EXPANSIONS N/A N/A EXPANSIONS N/A N/A
GETPAGES 9449.00 18898 GETPAGES 12817.33 115356
BUFFER UPDATES 2026.00 4052 BUFFER UPDATES 13184.56 118661
SYNCHRONOUS WRITE 1.00 2 SYNCHRONOUS WRITE 0.00 0
SYNCHRONOUS READ 76.50 153 SYNCHRONOUS READ 51.67 465
SEQUENTIAL PREFETCH 255.00 510 SEQUENTIAL PREFETCH 1656.22 14906
LIST PREFETCH 0.00 0 LIST PREFETCH 0.00 0
DYNAMIC PREFETCH 0.00 0 DYNAMIC PREFETCH 0.00 0
PAGES READ ASYNCHR.8121.00 16242 PAGES READ ASYNCHR. 1356.00 12206
Figure 75. Accounting Long Report Extract: Increased Buffer Pool BP1 Size
The statistics report in Figure 76 on page 124 also shows improvements at a

system level when compared with Figure 73 on page 121. Of particular interest
is the value for S.PRF.PAGES/S.PRF.READ, indicating that almost six pages for
workfile prefetch are read (see Figure 76 on page 124).
The overall number of reads, both sequential and synchronous, have been
reduced because of the increase in buffer pool size.
In addition to the improvements in read efficiency, PAGES WRITTEN PER WRITE

I/O shows a marked improvement, from 3.84 to 23.86. This improvement means
that the number of physical writes to DASD have been dramatically reduced.

STATISTICS REPORT - LONG
SCOPE: MEMBER
BP1 GENERAL QUANTITY BP1 READ OPERATIONS QUANTITY
---------------------------------- --------------------------- --------
CURRENT ACTIVE BUFFERS 423.80 GETPAGE REQUEST 210.7K
UNAVAIL.BUFFER-VPOOL FULL 0.00 GETPAGE REQUEST-SEQUENTIAL 210.0K
GETPAGE REQUEST-RANDOM 918.00
NUMBER OF DATASET OPENS 0.00
SYNCHRONOUS READS 2392.00
BUFFERS ALLOCATED - VPOOL 5000.00 SYNCHRON. READS-SEQUENTIAL 2628.00
BUFFERS ALLOCATED - HPOOL 0.00 SYNCHRON. READS-RANDOM 0.00
HPOOL BUFFERS BACKED 0.00
GETPAGE PER SYN.READ-RANDOM N/C
BP1 WRITE OPERATIONS QUANTITY
---------------------------------- SEQUENTIAL PREFETCH REQUEST 41736.00
BUFFER UPDATES 318.5K SEQUENTIAL PREFETCH READS 29235.00
PAGES WRITTEN 105.9K PAGES READ VIA SEQ.PREFETCH 112.1K
BUFF.UPDATES/PAGES WRITTEN 2.06 S.PRF.PAGES READ/S.PRF.READ 5.85
SYNCHRONOUS WRITES 0.00 PAGE-INS REQUIRED FOR READ 0.00

PAGES WRITTEN PER WRITE I/O 23.86
HORIZ.DEF.WRITE THRESHOLD 0.00

VERTI.DEF.WRITE THRESHOLD 707.00
DM CRITICAL THRESHOLD 0.00
WRITE ENGINE NOT AVAILABLE 0.00
Figure 76. Statistics Long Report Extract: Increased Buffer Pool BP1 Size
Using the functions of DB2 PM it has been possible to trace the cause of a
constrained buffer pool problem with class 1 elapsed time and class 3
suspension and rectify the situation. Naturally once this problem has been
resolved it is important to monitor the situation a little more closely than normal
with DB2 PM, as the problem may have been caused by unusually high
workloads or other atypical events. The monitoring strategy can return to
normal once a period of stability has been reached.
124 DB2 PM
5.3 Class 1 Elapsed Time Problem
The scenario demonstrates how DB2 PM can help you detect and analyze
problems in a transaction processing environment. The problem is inefficient
access path attributable to an incorrectly defined host variable.

• Exception processing
• Diagnosis of thread
• History function
• Explain.
The data collector must be active to enable the History function.
To define an exception threshold for the transaction elapsed time, select option
4, Maintain parameter data sets, from the IBM Database 2 Performance Monitor
panel. You are presented with the Data Set Maintenance Menu. Select option 1,
Maintain exception thresholds. The Exception Threshold Category Selection
panel (see Figure 77) is displayed showing accounting and statistics categories
for which you can define exception criteria.
Exception Threshold Category Selection

Command ===> ______________________________________________________________
Select one or more categories, then press Enter. Overtype with space to
deselect any category. Request EXIT when complete.
Category
> Elapsed, CPU and Waiting Times per Plan Execution
_ Elapsed, CPU and Waiting Times per Program Execution
_ CPU Times per Address Space
_ SQL Statements per Plan Execution
_ SQL Statements per Program Execution
_ SQL Statements per System
_ Subsystem Events per Plan Execution
_ Subsystem Events per System
_ Locking Activity per Plan Execution
_ Locking Activity per System
_ RID List Processing per Plan Execution
_ RID List Processing per System
_ Query Parallelism per Plan Execution
_ Query Parallelism per System
_ Buffer Pools Activity per Plan Execution
_ Buffer Pools Activity per System
_ Distributed Activity per Location per Plan Execution
_ Distributed Activity per System
_ Distributed Activity per Location per System
_ IFI and Data Capture Activity per Plan Execution
_ IFI Activity per System
_ EDM Pool Activity per System
_ Open/Close Activity per System
_ Plan/Package Processing per System
_ Log Activity per System
Figure 77. Exception Threshold Category Selection Panel: Class 1 Elapsed Time Problem

After you select a category, the Exception Threshold Field Selection panel (see
Figure 78 on page 126) is displayed showing fields related to that category. You
can choose any number of entries as exception fields.
Exception Threshold Field Selection

Command ===> ______________________________________________________________
Select one or more fields, then press Enter. Overtype with space to
deselect any field. Request EXIT when complete.
Field category . . : Elapsed, CPU and Waiting Times per Plan Execution
Field Description
> ADRECETT Elapsed time in application (Class 1)
_ ADTSUST Total Class 3 suspensions time
_ ADCPUT CPU time in application (Class 1)
_ ADTWTAP Total wait time in application (Class 1)
_ ADDB2ETT Elapsed time in DB2 (Class 2)
_ ADDBCPUT CPU time in DB2 (Class 2)
_ ADTWTDB Total wait time in DB2 (Class 2)
_ ADTSUSC Total Class 3 suspensions
_ QWACAWTL Lock/latch suspensions time (Class 3)
_ ADLLSUSC Lock/latch suspensions (Class 3)
_ QWACAWTI Synchronous I/O susp. time (Class 3)
_ ADIOSUSC Synchronous I/O suspensions (Class 3)
_ QWACAWTR Other read I/O susp. time (Class 3)
_ ADARSUSC Other read I/O suspensions (Class 3)
_ QWACAWTW Other write I/O susp. time (Class 3)
_ ADAWSUSC Other write I/O suspensions (Class 3)
_ QWACAWTE Serv.task switch susp. time (Class 3)
_ ADSTSUSC Serv.task swtch suspensions (Class 3)
-- End of Items --
Figure 78. Exception Threshold Field Selection Panel: Class 1 Elapsed Time Problem
After you select Elapsed time in application (Class 1) as the exception field,
specify the warning and problem thresholds. The threshold values are
measured in seconds (see Figure 79 on page 127).
126 DB2 PM
Command ===> _______________________________________________________________
ENTRY 1 OF 1

Field ID . . . . . : ADRECETT
Description . . . . : Elapsed time in application (Class 1)
More: +
Active . . . . . . . . . . . . . 1 1=Yes 2=No

4=Commit 5=Thread

Warning threshold . . . . . . . . 5
Problem threshold . . . . . . . . 10
Local location . . . . . . . . . *
Group name . . . . . . . . . . . *
Member name . . . . . . . . . . . *
Subsystem ID . . . . . . . . . . *
Requester location . . . . . . . *
Connect . . . . . . . . . . . . . *
Planname . . . . . . . . . . . . *
Corrname . . . . . . . . . . . . *
F1=Help F3=Exit F5=Add F6=Delete F7=Up F8=Down
F10=Previous F11=Next F12=Cancel
Figure 79. Exception Threshold Field Details Panel: Class 1 Elapsed Time Problem

Main Menu to get to the Exception Processor panel. Invoke periodic exception
processing by selecting Periodic from the Exception Processor panel. Specify
the periodic units and periodic interval (see Figure 80).
The DB2RES3.THRESH01 exception threshold data set contains the exception

values defined on the Exception Threshold Category Selection and Exception
Threshold Field Selection panels (see Figure 77 on page 125 and Figure 78 on
page 126).
Exception Processor

/ Periodic
Options
2=Minutes
1-120 Minutes
> Log file data set output needed

Name . . . . . . . . . ¢DB2RES3.THRESH01¢______________________________
----------------------------------------------------
| DGOM930 Exception processor has been initialized |
----------------------------------------------------
Command ===> ___________________________________________________________
Figure 80. Exception Processor Panel: Class 1 Elapsed Time Problem
128 DB2 PM
After some time the transaction requires more than 10 seconds, so a periodic
exception occurs, and an Exception Notification window is displayed during your
DB2 PM session (see Figure 81).
Note: If the data collector is active, you can log off the system while periodic
exception processing is running. Any periodic exception messages issued while
you are offline are gathered by the data collector and written to the periodic
exception list, when they can be examined using the LOOK command. You are
notified of any periodic exceptions when you next log on to the TSO system.

Command ===> _________________________________________________________________
_
ST11DB2F DB2F V4
To display a thread, plac

--------------------------------------------
Primauth Planname n| | Class 2
_ STCIMS D | Time . . : 95/05/24 10:56:22 |03.60278
_ STCDB2 CT410 N| |0.000069
_ STCDB2 CPPM410 N | Periodic Exceptions |3.060885
_ STCDB2 CPPM410 N | Problem . . . . . . . . . . . : 1 |0.050353
_ STCDB2 CPPM410 D | Warning . . . . . . . . . . . : 0 |3.941159
_ STCDB2 N| |0.198706
_ SEB N | Exception Events | N/P
_ OLS OLSTRANS N | Deadlock . . . . . . . . . . . : 0 | N/P
_ OLS CT410 N | Timeout . . . . . . . . . . . : 0 | N/P
_ HBB DB2PM410 N | EDM Pool Full . . . . . . . . : 0 | N/P
_ DB2SYSA DB2ADMP N | Authorization Failure . . . . : 0 | N/P
_ CICSUSER N | Thread Commit Indoubt . . . . : 0 | N/P
-- End of Thread list -- | CF rebuild/alter start . . . . : 0 |
| CF rebuild/alter end . . . . . : 0 |
| |
| F1=Help F12=Cancel |
---------------------------------------------

Figure 81. Exception Notification Window: Class 1 Elapsed Time Problem

From any of the DB2 PM Online Monitor panels except the LOOK-related panels,
issue the LOOK command to obtain more information on the exceptions. The
Look Selections menu is displayed (see Figure 82).
Look Selections
Command ===> ________________________________________________________

Figure 82. Look Selections Menu: Class 1 Elapsed Time Problem
Select option 1, Periodic Exceptions, and press Enter. The Periodic Exceptions
List window is displayed (see Figure 83 on page 131).
From the Periodic Exceptions List window, select the exception you want to
check.
130 DB2 PM
Look Selections
-----------------------------------------------------------------------------
| Command ===> ______________________________________________________________ |
| |
| |
| Last Interval . . . . . . . . . . . . . : 95/05/10 10:57:54.64 |
| |
| Descr |
| -------- ------------------ -------- ------------ -------- ---------- |
| S 10:57:51 ST11DB2F ¢BLANK¢ DB2F ¢BLANK¢ OLSRUN3 |
| ¢BLANK¢ OLS OLSTRANS BATCH ¢BLANK¢ |
| |
| _ 10:57:54 ST11DB2F ¢BLANK¢ DB2F ¢BLANK¢ OLSRUN3 |
| ¢BLANK¢ OLS OLSTRANS BATCH ¢BLANK¢ |
| |
-----------------------------------------------------------------------------¢
Figure 83. Periodic Exceptions List Window: Class 1 Elapsed Time Problem

The Thread Detail panel (Figure 84) shows the exception transaction.
Note: If the transaction has completed, the Thread Detail panel is displayed only
if the data collector is active. If the data collector is not active, no further online
information is displayed.
From the Thread Detail panel, issue the DIAGNOSE command to display the
Diagnosis of Thread window, which contains more information related to the
thread.

Command ===> diagnose_________________________________________________________
For details, place any character next to heading, then press Enter.
More: +
_ Thread Identification
Primauth . . . . . : OLS Correlation Name . . . : OLSRUN3
Planname . . . . . : OLSTRANS Connection type . . . . : TSO
Connection ID . . : BATCH Type . . . . . . . . . : ALLIED
Requesting Location: ST11DB2F Status . . . . . . . . : DB2
_ Current Package . . . . . . . . . . . : DSNTEP2
_ Times Elapsed CPU
Class 1 . . . . . . . . . . . . . . . . . : 2:22.938435 1:42.024217
Class 2 . . . . . . . . . . . . . . . . . : 2:20.080421 1:41.019605
Class 3 . . . . . . . . . . . . . . . . . : 16.190264 N/A
Class 7 . . . . . . . . . . . . . . . . . : N/P N/P
Class 8 . . . . . . . . . . . . . . . . . : N/P N/A
_ Locking Activity
Timeouts . . . . . . . . . . . . . . . . . : 0
Deadlocks . . . . . . . . . . . . . . . . : 0
Suspensions . . . . . . . . . . . . . . . : 10001
Lock escalations . . . . . . . . . . . . . : 0
Maximum page locks held . . . . . . . . . : 2
_ Locked Resources
_ RID List Processing
Unsuccessful - any reason . . . . . . . . : 0
DML . . . : 3 Commits . . . . . . . . : 0
DCL . . . : 0 Rollbacks . . . . . . . : 0
F12=Cancel
Figure 84. Thread Detail Panel Invoking Diagnose: Class 1 Elapsed Time Problem
132 DB2 PM
The Diagnosis of Thread window in Figure 85 shows where most of the time was
spent for this thread and indicates a possible problem with the buffer pool size.
Because most of the time spent is in active processing, select the Actively
Processing field to obtain more information.
-----------------------------------------------------------------------------
| 95/05/10 10:59 Diagnosis of Thread OLS OLSTRANS |
| Command ===> _____________________________________________________________ |
| |
| HISTORY 95/05/10 10:58:31 |
| More: + |
| |
| |
| |
| s Actively processing . . . . . . . . . . . . . . . . . . . : 71.23 |
| _ Locks and Latches . . . . . . . . . . . . . . . . . . . . : 11.36 |
| |
| |
| |
| |
| |
| |
| |
-----------------------------------------------------------------------------
Figure 85. Diagnosis of Thread Window: Class 1 Elapsed Time Problem
From the Active Processing window (see Figure 86), we recommend that you
check the access path. Go back to the Thread Detail panel to check the current
SQL statement.
--------------------------------------------------------------------------
| Active Processing OLS OLSTRANS |
| Command ===> __________________________________________________________ |
| |
| HISTORY 95/05/10 10:58:31 |
| More: + |
| |
| Percent of DB2 elapsed time thread was actively processing : 71.23 |
| Buffer pool read hit ratio for BP0 (%) . . . . . . . . . . : 99.98 |
| Global trace auto start . . . . . . . . . . . . . . . . . : N/P |
| |
| |
| |
| If active processing is higher than expected: |
| o Inefficient buffer pool management increases processor usage. |
| o Check that the access paths are appropriate for the current state |
| of the data. Perhaps the plan should be rebound, or a table |
| should be reorganized, or the catalog statistics updated. |
--------------------------------------------------------------------------
Figure 86. Active Processing Window: Class 1 Elapsed Time Problem

From the Thread Detail panel, select SQL Statement and Package (see
Figure 87).

Command ===> _________________________________________________________________
For details, place any character next to heading, then press Enter.
More: - +
Deadlocks . . . . . . . . . . . . . . . . : 0
Suspensions . . . . . . . . . . . . . . . : 10001
Lock escalations . . . . . . . . . . . . . : 0
Maximum page locks held . . . . . . . . . : 2
_ Locked Resources
_ RID List Processing
Unsuccessful - any reason . . . . . . . . : 0
DML . . . : 3 Commits . . . . . . . . : 0
DCL . . . : 0 Rollbacks . . . . . . . : 0
_ Buffer Manager Activity
Getpage requests . . . . . . . . . . . . . : 30001
Buffer updates . . . . . . . . . . . . . . : 0
Prefetch requests . . . . . . . . . . . . : 0
Synchronous I/O . . . . . . . . . . . . . : 6
s SQL Statement and Package . . . . . . . . : OLSTEST3
Distributed Data
Requester elapsed time . . . . . . . . . . : N/P
_ IFI (Class 5) and Data Capture
_ Query Parallelism Data
Data Sharing Locking Activity
Suspensions . . . . . . . . . . . . . . . : N/P
_ Stored Procedures
F12=Cancel
Figure 87. Thread Detail Panel (SQL Statement and Package): Class 1 Elapsed Time
Problem
You are presented with the SQL Statement and Package window. Issue the
EXPLAIN command to get an explanation of the SQL statement (see Figure 88 on
page 135).
134 DB2 PM
----------------------------------------------------------------------------
| SQL Statement and Package ROW 1 TO 2 OF 2 |
| Command ===> explain_____________________________________________________ |
| |
| |
| Location . . . . . . . . . . . . . : ST11DB2F |
| Collection ID . . . . . . . . . . : OLS_TRANS |
| Program Name . . . . . . . . . . . : OLSTEST3 |
| Consistency Token . . . . . . . . : X¢155B3E2800260644¢ |
| Version |
| N/P |
| |
| Stored procedure . . . . . . . . . : N/P |
| Statement type . . . . . . . . . . : SELECT |
| Statement number . . . . . . . . . : 115 |
| Thread status . . . . . . . . . . : In DB2 |
| |
| SQL Statement |
| SELECT EMPNO, LASTNAME, PHONENO |
| INTO :H, :H, :H |
| FROM DSN8410.EMP |
| WHERE EMPNO=:H |
| **************************** BOTTOM OF DATA ***************************** |
| F1=Help F3=Exit F5=Auto F6=History F7=Up F8=Down |
| F12=Cancel |
---------------------------------------------------------------------------
Figure 88. SQL Statement and Package Window: Class 1 Elapsed Time Problem
The result returned by the EXPLAIN command (Figure 89 on page 136) shows
that a Table space scan - no index will be used .

----------------------------------------------------------------------------
| DB2 Explain Output |
| Command ===> ____________________________________________________________ |
| |
| |
| Local location . . . . . . . . . . : ST11DB2F DB2F V4 |
| Current server . . . . . . . . . . : ST11DB2F DB2F V4 |
| |
| _ Package . . . . . . . . . . . . . : OLS_TRANS.OLSTEST3 |
| Version |
| |
| Explain executed at . . . . . . . : 95/05/10 12:35:04.84 |
| |
| -----------------------------------SQL Text------------------------------ |
| _ SELECT EMPNO, LASTNAME, PHONENO |
| INTO :EMPNO1, :LASTNAME1, :PHONENO1 |
| WHERE EMPNO=:EMPLNO |
| |
| _ Host variable definitions |
| |
| -----Access path summary for query block 1 step 1----- |
| Tablespace scan - no index will be used |
| Lock mode is share lock for the page |
| DGOM762 This statement was explained at bind time |
| F12=Cancel |
----------------------------------------------------------------------------
Figure 89. DB2 Explain Output Panel: Class 1 Elapsed Time Problem
From the DB2 Explain Output panel, request the DB2 catalog information for the
EMP table (see Figure 90 on page 137) to find out whether any index has been
created on the table.
136 DB2 PM
----------------------------------------------------------------------------
| Command ===> ____________________________________________________________ |
| |
| |
| |
| _Package . . . . . . . . . . . . . : OLS_TRANS.OLSTEST3 |
| Version |
| |
| |
| -----------------------------------SQL Text------------------------------ |
| |
| _ Host variable definitions |
| |
| s Table DSN8410 EMP |
| |
| _ PLAN_TABLE details for step |
| ---- End of Explain details ---- |
| |
| F12=Cancel |
----------------------------------------------------------------------------
Figure 90. DB2 Explain Output (Table Information): Class 1 Elapsed Time Problem
The Table Information window (Figure 91) indicates that the EMP table has
indexes. Select Indexes to obtain detailed index information.
----------------------------------------------------------------------------
| Table Information |
| Command ===> ____________________________________________________________ |
| |
| More: + |
| |
| Table name . . . . . . . . . . . . . . . . . : DSN8410.EMP |
| Type . . . . . . . . . . . . . . . . . . . . : Table |
| s Indexes . . . . . . . . . . . . . . . . . . : Yes |
| Database name . . . . . . . . . . . . . . . : DSN8D41A |
| Table space name . . . . . . . . . . . . . . : DSN8S41E |
| Table identifier . . . . . . . . . . . . . . : 14 |
| Columns . . . . . . . . . . . . . . . . . . : 14 |
| Rows . . . . . . . . . . . . . . . . . . . : 42 |
| Status . . . . . . . . . . . . . . . . . . : Has primary index |
| Maximum record length . . . . . . . . . . . : 107 |
| Pages . . . . . . . . . . . . . . . . . . . : 2 |
| Percentage of pages used . . . . . . . . . . : 2 |
| |
| F12=Cancel |
---------------------------------------------------------------------------
Figure 91. Table Information Window: Class 1 Elapsed Time Problem

From the Index Information window (see Figure 92 on page 138) select Key
columns (see Figure 92 on page 138) to find out which is the index key column.
---------------------------------------------------------------------------
| Index Information |
| Command ===> ____________________________________________________________ |
| |
| More: + |
| |
| Index name . . . . . . . . . . . : DSN8410.XEMP1 |
| Index space name. . . . . . . . . : XEMP1 |
| Table name . . . . . . . . . . . : DSN8410.EMP |
| Database name . . . . . . . . . . : DSN8D41A |
| Buffer pool . . . . . . . . . . . : BP0 |
| s Key columns . . . . . . . . . . . : 1 |
| Subpage size (bytes) . . . . . . : 512 |
| Unique rule . . . . . . . . . . . : Primary - Unique |
| Clustering index . . . . . . . . : Yes |
| Currently clustered . . . . . . . : Yes |
| Cluster ratio . . . . . . . . . . : 100 |
| Full key card . . . . . . . . . . : 42 |
| First key card . . . . . . . . . : 42 |
| |
| F12=Cancel |
---------------------------------------------------------------------------
Figure 92. Index Information Window: Class 1 Elapsed Time Problem
The Key Column Information window (Figure 93) indicates that the column name
is EMPNO and its length is 6 bytes.
---------------------------------------------------------------------------
| Key Column Information |
| Command ===> ____________________________________________________________ |
| |
| |
| |
| Column name . . . . . . . . . . . : EMPNO |
| Table name . . . . . . . . . . . : DSN8410.EMP |
| Index name . . . . . . . . . . . : DSN8410.XEMP1 |
| Position . . . . . . . . . . . . : 6 |
| Sequence . . . . . . . . . . . . : Ascending |
| Type . . . . . . . . . . . . . . : Char |
| Length . . . . . . . . . . . . . : 6 |
| Scale . . . . . . . . . . . . . . : 0 |
| Null value . . . . . . . . . . . : No |
| Second highest value . . . . . . : 200330 |
| Second lowest value . . . . . . . : 000020 |
| Last RUNSTATS . . . . . . . . . . : 1995-05-01-17.13.29.734659 |
| |
| F12=Cancel |
---------------------------------------------------------------------------
Figure 93. Key Column Information Window: Class 1 Elapsed Time Problem
138 DB2 PM
Returning to the DB2 Explain Output panel (see Figure 94 on page 139), you can
see that the SQL statement uses where EMPNO=:EMPLNO . Because there is
an index on EMPNO, the index should have been used.
Select the Host variable definitions to check the definitions.
----------------------------------------------------------------------------
| Command ===> ____________________________________________________________ |
| |
| |
| |
| _ Package . . . . . . . . . . . . . : OLS_TRANS.OLSTEST3 |
| Version |
| |
| |
| -----------------------------------SQL Text------------------------------ |
| |
| s Host variable definitions |
| |
| -----Access path summary for query block 1 step 1----- |
| Tablespace scan - no index will be used |
| Lock mode is share lock for the page |
| |
| F12=Cancel |
----------------------------------------------------------------------------
Figure 94. DB2 Explain Output (Host Variables): Class 1 Elapsed Time Problem
The Host Variable Definition window (see Figure 95 on page 140) indicates that
the host variable EMPLNO has a length of 7 bytes. This explains why the index
has not been used. The wrong length was specified when the host variable was
defined. In order to be matching indexable, the length of the host variable must
be equal to or less than the length of the column.

----------------------------------------------------------------------------
| Host Variable Definition ROW 1 to 4 of 4 |
| Command ===> ____________________________________________________________ |
| |
| |
| |
| |
| Name Type Length |
| EMPNO1 Fixed Character 6 |
| LASTNAME1 Fixed Character 15 |
| PHONENO1 Fixed Character 4 |
| EMPLNO Fixed Character 7 |
| **************************** BOTTOM OF DATA ***************************** |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| F12=Cancel |
----------------------------------------------------------------------------
Figure 95. Host Variable Definition Window: Class 1 Elapsed Time Problem
140 DB2 PM
5.4 Access Path Problem
This scenario shows a situation where the expected access path has changed,
causing extended elapsed times for a specific transaction. The problem arises
after a change to application code.

• Accounting exception report
• Explain.
The daily accounting exception report identifies a transaction performing outside

the specifications (see Figure 96 on page 142) determined during application
design. The expected elapsed time for the transaction should be under 1 second
or very close to that value. The problem exception threshold is set at 2 seconds
to identify any transaction exceeding that limit, and a number of exception
events have been detected.

EXCEPTION
DB2 VERSION: V4
PRIMAUTH #OCCURS #ROLLBK SELECTS INSERTS UPDATES

PLANNAME #DISTRS #COMMIT FETCHES OPENS CLOSES
--------------------------- ------- ------- ------- ------- -------
DB2RES2 19 0 0.00 0.00 0.00

DSNTEP41 0 19 236.00 1.00 1.00
----------------------------------------------------------------
|PROGRAM NAME TYPE #OCCURS SQLSTMT CL7 ELAP.TIME
|DSNTEP2 PACKAGE 19 240.00 17.101322
----------------------------------------------------------------
******************************************************************
* TYPE FIELD ID FIELD DESCRIPTION
* FIELD QUALIFIER
* PROBLEM ADRECETT ELAPSED TIME IN APPLICATION (CLASS 1)
*
******************************************************************
DELETES CLASS1 EL.TIME CLASS2 EL.TIME GETPAGES SYN.READ LOCK SUS

PREPARE CLASS1 CPUTIME CLASS2 CPUTIME BUF.UPDT TOT.PREF #LOCKOUT
------- -------------- -------------- -------- -------- --------
0.00 17.246470 17.101382 7808.11 10.74 0.11

1.00 2.705693 2.607943 0.00 255.00 0
---------------------------------------
CL7 CPU TIME CL8 SUSP.TIME CL8 SUSP|
2.607895 14.403277 330.47|
---------------------------------------
****************************************************************
BY VALUE THRESHOLD *
*
THREAD 17.246470 > 2 *
*
****************************************************************
Figure 96. Accounting Exception Report: Access Path Problem
Run an accounting long report for the specific primauth and plan name to gain a
clearer picture of where the increased time has been spent. Figure 97 on
page 143 shows that most of the total class 3 suspension time of nearly 10
seconds has been spent suspended for both synchronous and other read I/Os.
You certainly do not expect an OTHER READ I/O as this implies that your
transaction is performing prefetch. Your expectation is for the transaction to
perform random reads using an index. You are now suspicious of the access
path, particularly as the DB2 PM accounting report shows OTHER READ I/O
suspensions. In addition to the unexpected OTHER READ I/O, SYNCHRON. I/O is
142 DB2 PM
also high. This could be due to prefetched pages being stolen from the buffer
pool before the getpage is issued. When this occurs the page is read
synchronously.

ORDER: PLANNAME
DB2 VERSION: V4
PLANNAME: DB2RES2B

------------ -------------- --------------
ELAPSED TIME 14.517900 14.486477
CPU TIME 4.479270 4.468278
TCB 4.479270 4.468278
TCB-STPROC 0.000000 0.000000
CPU-PARALL 0.000000 0.000000

-------------- ------------ --------
LOCK/LATCH 0.014774 19.00
SYNCHRON. I/O 5.520769 898.00
OTHER READ I/O 4.189498 225.00
OTHER WRTE I/O 0.000000 0.00
TOTAL CLASS 3 9.725041 1142.00
Figure 97. Accounting Long Report Extract: Access Path Problem
Using the DB2 PM Online Monitor Explain function you explain the application
package. Explain shows that a table space scan is being performed and no
index is being used. You make a selection to look at the characteristics of the
DB2RES2.COLBABY4 table (see Figure 98 on page 144).

DB2 Explain Output
Command ===> __________________________________________________________________
Local location . . . . . . . : ST11DB2F DB2F V4

Current server . . . . . . . : ST11DB2F DB2F V4
_ Package . . . . . . . . . . . . . : DB2RES2.S.TEST3
Version
Explain executed at . . . . : 95/05/12 19:10:23.99

----------------------------------SQL Text------------------------------
_ SELECT NAME,TBNAME,DEFAULT,REMARKS,LABEL
INTO :NAME, :TBNAME, :DEFAULT,
:REMARKS, :LABEL
FROM DB2RES2.COLBABY4
WHERE TBNAME = :TBNAME AND NAME = :NAME AND
HIGH2KEY= :HIGH2KEY
----- Access path summary for query block 1 step 1 -----

Table space scan - no index will be used
Standard sequential prefetch will be performed
Lock mode is share lock for the page
Page range scan will not be used
s Table DB2RES2 COLBABY4
_ PLAN_TABLE details for step
---- End of Explain details ----
Figure 98. DB2 Explain Output Panel: Access Path Problem
The Table Information window (see Figure 99) indicates that the table has
indexes defined. To view the index information, select Indexes .
DB2 Explain Output

-----------------------------------------------------------------------------
| Command ===> ______________________________________________________________ |
| |
| |
| Local location . . . . . . . : ST11DB2F DB2F V4 |
| Current server . . . . . . . : ST11DB2F DB2F V4 |
| More: + |
| Table name . . . . . . . . . . . . . : DB2RES2.COLBABY4 |
| Type . . . . . . . . . . . . . . . . : Table |
| s Indexes . . . . . . . . . . . . . . . : Yes |
| Database name . . . . . . . . . . . . : DB2D0004 |
| _ Table space name . . . . . . . . . . : DB2TS004 |
| Table identifier . . . . . . . . . . : 3 |
| Columns . . . . . . . . . . . . . . . : 21 |
| Rows . . . . . . . . . . . . . . . . : 309495 |
| Status . . . . . . . . . . . . . . . : Indeterminate |
| Maximum record length . . . . . . . . : 652 |
| Pages . . . . . . . . . . . . . . . . : 7755 |
| Percentage of pages used . . . . . . : 89 |
| Last RUNSTATS . . . . . . . . . . . . : 1995-05-11-16.22.44.981040 |
| EDIT procedure name . . . . . . . . . : |
-----------------------------------------------------------------------------
Figure 99. Table Information Window: Access Path Problem
144 DB2 PM
The Index Information window (see Figure 100 on page 145) confirms that the
index is unique, made up of three columns, and in good shape, with a value of
100 for Cluster ratio and Yes for Currently clustered .
The information presented in the Index Information window is current as

Runstats shows that it has been run very recently. Select Key columns to look
at the key columns for the index.
DB2 Explain Output

-----------------------------------------------------------------------------
| C ------------------------------------------------------------------- ___ |
| | Index Selection ROW 1 TO 2 OF 2 | |
| L | C ------------------------------------------------------------------- |
|C| | Index Information ||
| | L | Command ===> ____________________________________________________ | |
| | | | |
| |C| ||
| | | Local location . . . . . . . : ST11DB2F DB2F V4 | |
| s | | Current server . . . . . . . : ST11DB2F DB2F V4 ||
| | | More: + | |
| _ | | _ Index name . . . . . . . . : DB2RES2.DB2TSI04 ||
| |s| Index space name . . . . . : DB2TSI04 ||
| |_| Table name . . . . . . . . : DB2RES2.COLBABY4 ||
| |*| Database name . . . . . . . : DB2D0004 ||
| | | Buffer pool . . . . . . . . : BP0 | |
| | | s Key columns . . . . . . . . : 3 | |
| | | Subpage size (bytes) . . . : 4096 | |
| | | Unique rule . . . . . . . . : Unique | |
| | | Clustering index . . . . . : Yes | |
| | | Currently clustered . . . . : Yes | |
-- | | Cluster ratio . . . . . . . : 100 ||
-- | Full key card . . . . . . . : 309495 ||
| First key card . . . . . . : 235 ||
| Levels . . . . . . . . . . : 3 ||
| Leaf pages . . . . . . . . : 4365 ||
| Close rule . . . . . . . . : Close table ||
| Last RUNSTATS . . . . . . . : 1995-05-11-16.22.44.981040 |
| Allocated space . . . . . . : 0 |
| Erase rule . . . . . . . . : No |
| Index type . . . . . . . . : 2 |
-------------------------------------------------------------------
Figure 100. Index Information Window: Access Path Problem
Here Figure 101 on page 146 identifies the three key columns available on the
index. With this information you examine the SQL statement in the DB2 Explain
Output panel (see Figure 98 on page 144). You now recognize that the change
to the access path has been caused by the omission of the first key column of
the index, which has forced a table space scan.

DB2 Explain Output
-------------------------------------------------------------------
| Index Information |
-----------------------------------------------------------------------
| Key Column Selection ROW 1 TO 3 OF 3 |
| Command ===> _________________________________________________________|
| |
| |
| Local location . . . . . . . : ST11DB2F DB2F V4 |
| Current server . . . . . . . : ST11DB2F DB2F V4 |
| |
| Index name . . . : DB2RES2.DB2TSI04 |
| Table name . . . : DB2RES2.COLBABY4 |
| |
| Column Type Length Sequence |
| _ TBCREATOR CHAR 8 Ascending |
| _ TBNAME VARCHAR 18 Ascending |
| _ NAME VARCHAR 18 Ascending |
| ***************************** BOTTOM OF DATA *************************|
| |
| |
| |
| |
| |
| |
| |
-----------------------------------------------------------------------
Figure 101. Key Column Selection Window: Access Path Problem
After you correct the SQL statement (see Figure 102 on page 147), run explain
once again against the package. The explain output confirms the access path to
be a matching index scan. This is the access path expected for this transaction.
146 DB2 PM
DB2 Explain Output
Command ===> __________________________________________________________________

Explain executed at . . . . : 95/05/12 09:31:25.95
----------------------------------SQL Text------------------------------
_ SELECT NAME,TBNAME,DEFAULT,REMARKS,LABEL
INTO :NAME, :TBNAME, :DEFAULT,
:REMARKS, :LABEL
FROM DB2RES2.COLBABY4
WHERE TBCREATOR = :TBCREATOR AND TBNAME = :TBNAME AND
NAME = :NAME AND HIGH2KEY = :HIGH2KEY
----- Access path summary for query block 1 step 1 -----

Matching index scan with scan of referenced data pages
Number of matching columns: 3. The index has 3 columns
Clustered index scan will be used
Lock mode is share lock for the page
Page range scan will not be used
_ Table DB2RES2 COLBABY4

_ Index DB2RES2 DB2TSI04
_ PLAN_TABLE details for step
---- End of Explain details ----
Figure 102. DB2 Explain Output (Corrected SQL Statement): Access Path Problem
To verify that the problem has been resolved, rerun the transaction, having first
enabled the Collect Data Report function for accounting information (see 5.1,
“Sort Problem” on page 104), and produce an accounting report.
The elapsed time shown in Figure 103 on page 148 has now returned to within
the expected value because a matching index scan has been used and OTHER
READ I/O has not been performed.

ORDER: PLANNAME
DB2 VERSION: V4
PLANNAME: DB2RES2G

------------ -------------- --------------
ELAPSED TIME 0.688626 0.642997
CPU TIME 0.057963 0.046088
TCB 0.057963 0.046088
TCB-STPROC 0.000000 0.000000
CPU-PARALL 0.000000 0.000000

-------------- ------------ --------
LOCK/LATCH 0.000000 0.00
SYNCHRON. I/O 0.521777 21.00
OTHER READ I/O 0.000000 0.00
OTHER WRTE I/O 0.000000 0.00
TOTAL CLASS 3 0.521777 21.00
Figure 103. Accounting Long Report Extract: With Expected Access Path
148 DB2 PM
5.5 Locking Problem
This scenario shows a situation where deadlocks are occurring between two
plans. One of the plans is new and has been recently introduced to the system.
DB2 PM alerts, in the form of event exceptions, are being triggered, informing
you of deadlock situations.

• Event exception processing
• Collect report data
• Lockout trace
• SQL trace
• Explain.
DB2 PM is configured such that the data collector and the EXCEPTIONEVENT
option within the data collector are active, enabling exception events to check for
critical DB2 subsystem problems, such as deadlocks.
Main Menu to get to the Exception Processor panel. Invoke the event exception
processing by selecting Exception event notification (see Figure 104).
Exception Processor

_ Periodic
/ Exception event notification
Options
Periodic units . . . . . . . . . . . . . . 1=Seconds
2=Minutes
Periodic interval . . . . . . . . . . . . 1-7200 Seconds
1-120 Minutes
_ Disable auto-display for problem exceptions
_ Sound alarm for exception warnings

Name . . . . . . . . . ¢DB2RES3.THRESH01¢______________________________
----------------------------------------------------
| DGOM930 Exception processor has been initialized |
----------------------------------------------------
Command ===> ___________________________________________________________
Figure 104. Exception Processor Panel: Locking Problem
Exception events (deadlocks) have been detected. The Exception Notification

window (Figure 105 on page 150) shows the extent of the problem.

Command ===> _________________________________________________________________
_
ST11DB2F DB2F V4
To display a thread, plac

--------------------------------------------
Primauth Planname n| | Class 2
_ STCIMS D | Time . . : 95/06/19 08:20:05 |03.60278
_ STCDB2 CT410 N| |0.000069
_ STCDB2 CPPM410 N | Periodic Exceptions |3.060885
_ STCDB2 CPPM410 N | Problem . . . . . . . . . . . : 0 |0.050353
_ STCDB2 CPPM410 D | Warning . . . . . . . . . . . : 0 |3.941159
_ STCDB2 N| |0.198706
_ SEB N | Exception Events | N/P
_ OLS OLSTRANS N | Deadlock . . . . . . . . . . . : 5 | N/P
_ OLS CT410 N | Timeout . . . . . . . . . . . : 0 | N/P
_ HBB DB2PM410 N | EDM Pool Full . . . . . . . . : 0 | N/P
_ DB2SYSA DB2ADMP N | Authorization Failure . . . . : 0 | N/P
_ CICSUSER N | Thread Commit Indoubt . . . . : 0 | N/P
-- End of Thread list -- | CF rebuild/alter start . . . . : 0 |
| CF rebuild/alter end . . . . . : 0 |
| |
| F1=Help F12=Cancel |
---------------------------------------------

Figure 105. Exception Notification Window: Locking Problem
To obtain more information on this event exception issue the LOOK command
from the command line. The Look Selections menu is displayed (see Figure 106).
Look Selections
Command ===> ________________________________________________________

Figure 106. Look Selections Menu: Locking Problem
150 DB2 PM
Select option 5, Exception Event Summary, and press Enter. The Exception Event
Summary window is displayed (see Figure 107 on page 151). On the Exception
Event Summary window, you can select the exception event for which you want
more detailed information.
-----------------------------------------------------------------------
| Command ===> ________________________________________________________ |
| |
| |
| Reporting Started . . . . . . . . . . . : 95/06/19 08:20:05 |
| Last Interval . . . . . . . . . . . . . : 95/06/19 08:47:27 |
| |
| Date Time IFCID |
| _ 95/06/12 06:25:46 172 |
| Deadlock |
| |
| _ 95/06/12 06:41:42 172 |
| Deadlock |
| |
| _ 95/06/12 06:43:42 172 |
| Deadlock |
| |
| _ 95/06/12 07:01:22 172 |
| Deadlock |
| |
| s 95/06/19 08:47:27 172 |
| Deadlock |
| |
-----------------------------------------------------------------------
Figure 107. Exception Event Summary Panel: Locking Problem
Figure 108 on page 152 shows the Deadlock Data panel, which identifies among
other items the plans, the resource and the page involved in the deadlock, the
state of the locks requested, and the holder of the resource and the waiter. With
this information you now have a clear picture of who is involved in the deadlock
and which DB2 resources are in contention.

---------------------------------------------------------------------
| Deadlock Data |
| Command ===> ______________________________________________________ |
| |
| THERE IS NO ADDITIONAL INFORMATION ABOVE THIS LINE. |
| More: + |
| IFCID . . . . . . . . . . . . . . . . . : 172 |
| |
| Number of resources involved in deadlock : 2 |
| Deadlock interval counter . . . . . . . : 2 |
| Time deadlock detected . . . . . . . . . : 08:47:27 |
| |
| Locked resource |
| Type . . . . . . . . : DATAPAGE |
| Name . . . . . . . . : Database : 266 Object : 2 |
| Page # : X¢000002¢ |
| |
| Holder |
| Member/DBMS identifier . . . . . : DB2F |
| Plan name . . . . . . . . . . . : REVP11 |
| Correlation identifier . . . . . : DB2RES23 |
| Connection identifier . . . . . : BATCH |
| LUW identifier . . . . . . . . . : USIBMST .ST11DB2F.AB3E3B8E68E7 |
| State . . . . . . . . . . . . . : X |
| Duration . . . . . . . . . . . . : COMMIT |
| |
| Attributes |
| CBS/RS . . . . . . . . . . . . : N |
| PRIVATE . . . . . . . . . . . : N |
| RESTART . . . . . . . . . . . : N |
| MODIFY . . . . . . . . . . . . : N |
| |
| Waiter |
| Member/DBMS identifier . . . . . : DB2F |
| Plan name . . . . . . . . . . . : REVP22 |
| Correlation identifier . . . . . : DB2RES24 |
| Connection identifier . . . . . : BATCH |
| LUW identifier . . . . . . . . . : USIBMST .ST11DB2F.AB3E3B96F60B |
| Requested function . . . . . . . : LOCK |
| State . . . . . . . . . . . . . : S |
| Duration . . . . . . . . . . . . : MANUAL |
| DB2 assigned worth value . . . . : 18 |
| |
| Attributes |
| CONDITIONAL . . . . . . . . . : N |
| AUTO-RELEASE . . . . . . . . . : N |
| CBS/RS . . . . . . . . . . . . : N |
| PRIVATE . . . . . . . . . . . : N |
| RESTART . . . . . . . . . . . : N |
| MODIFY . . . . . . . . . . . . : N |
| FORCE . . . . . . . . . . . . : N |
¢---------------------------------------------------------------------¢
Figure 108. Exception Event Detail Panel: Locking Problem
Because the deadlock situation in this scenario occurs regularly, you can use
the Collect Report Data function to collect trace data. Currently you know that
deadlocks are occurring and you know which plans and authids are involved. To
develop your diagnosis, however, you need more information. The lockout trace,
part of the locking report set, can provide clear, succinct information with a very
low overhead. It uses statistics trace class 1 and class 3 record IFCIDs 172, 196,
and 105 gathered to provide deadlock, timeout, and object identification
152 DB2 PM
information. Use the Collect Data Report function to obtain the required trace
records. If, however, your installation permits the direct use of current SMF data
for DB2 PM report generation, you do not have to use the Collect Data Report
function to obtain trace records for the lockout trace. Select option 6, Collect
Data Report, from the DB2 PM Online Monitor main menu and then enter option
1 to configure a task. On the Trace Configuration window fill in the Task
Description (use a meaningful name for your own ease of recognition) and set
the trigger to collect the data. We suggest that you trigger by Immediate Start
because the problem can be easily recreated. If the deadlocks are sporadic,
however, consider triggering by Exception event to start the data collection when
the exception event is detected. Select the Locking report set and then IFCID.
Collect Report Data

------------------------------------------------------------------------.
| Command ===> _________________________________________________________ |
| |
| |
| Task Description . . . . . . : Lockout |
| More: + |
| Trigger by . . . . . . . . . . 4 1=Time |
| 2=Periodic exception |
| 3=Exception event |
| 4=Immediate Start |
| |
| Enter one or more selection characters to start DB2 traces for specific|
| DB2 PM report sets or overtype with a blank to delete the selection. |
| |
| _ Accounting |
| _ Audit |
| _ I/O Activity |
| > Locking |
| _ Record Trace |
| _ SQL Activity |
| _ Record Trace |
| _ SQL Activity |
| _ Statistics |
| _ System Parameters |
| _ Utility Activity |
| |
| Enter one or more selection characters to qualify the data collection |
| or overtype with a blank to delete the selection. |
| |
| _ Data Type |
| > IFCID |
| > Requesting Location, Plan name and Authid |
| |
| 1024 OP Buffer size (K-bytes) |
| |
------------------------------------------------------------------------¢
Figure 109. Trace Configuration Window: Locking Problem
Select IFCIDs 172, 196, and 105 (see Figure 110 on page 154).

Collect Report Data
-------------------------------------------------------------------------
-------------------------------------------------------------------------|
| IFCID Selection ROW 1 TO 11 OF 21 |
| Command ===> __________________________________________________________ |
| |
| |
| Task Description . . . . . . : Lockout |
| |
| Enter one or more selection characters to start DB2 traces for specific |
| IFCIDs or overtype with a blank to delete the selection. |
| |
| _ Select all |
| |
| IFCID Description |
| _ 20 Lock summary |
| _ 21 IRLM request |
| _ 44 IRLM suspension (except drain lock) |
| _ 45 IRLM resumption (except drain lock) |
| > 105 DBID/OBID for database and tablespace translation |
| _ 107 Data set open/close information |
| > 172 Deadlock |
| > 196 Timeout |
| _ 211 Claim request |
| _ 212 Drain request |
| _ 213 IRLM suspension (drain lock only) |
| _ 214 IRLM resumption (drain lock only) |
| _ 215 Drain suspension |
| _ 216 Drain resumption |
| _ 218 Determine if lock avoidance techniques can be used |
| _ 223 Lock Avoidance |
| _ 226 Page Latch suspension |
| _ 227 Page Latch resumption |
| _ 251 Page set physical lock operations |
| _ 257 Details of IRLM notify request |
| _ 259 Page lock request or page lock negotiation request |
| -- End of IFCIDs -- |
-------------------------------------------------------------------------
Figure 110. IFCID Selection Window: Locking Problem
After you select your IFCIDs you are presented with the Trigger Immediately
window (see Figure 111 on page 155). Specify the destination of the trace data
and the criteria for stopping the active trace.
154 DB2 PM
Collect Report Data
----------------------------------------------------------------------
|----------------------------------------------------------------------|
| Trigger Immediately |
| Command ===> ________________________________________________________|
| |
| Task Description . . . . : Lockout |
| More: + |
| Output Data Set for DB2 trace data to be written to |
| Name . . . . . . . . . . ¢DB2RES2.LOCKOUT.TRACE¢ |
| Disposition . . . . . . 3 1=Append |
| 2=Overwrite |
| 3=New |
| |
| Start the DB2 traces immediately |
| |
| Stop the DB2 traces when any of the following conditions occur |
| > Elapsed time . . . . . . . . . . . . . . . 180 (seconds) |
| _ Number of records collected . . . . . . . . 0 |
| _ Thread termination |
| _ Number of IFCIDs collected . . . . . . . . 0 |
| For IFCID . . . . . . . . . . . . . . . . . 0 + |
| |
| |
| |
----------------------------------------------------------------------
Figure 111. Trigger Immediately Window: Locking Problem
To activate the collection of trace data specify option 2, Start, from the Collect
Report Data window and rerun the transactions causing the deadlock.
Use the collected data to produce a lockout trace (see Figure 112 on page 156).
The comprehensive information shown in the trace indicates that resource
DB2D0005 DB2TS005 page X′000002′ is held exclusively by DB2RES23 while
DB2RES24 is requesting an S lock on the same page. Concurrently DB2RES24
has an X lock on resource DB2D0001 DB2TS001 page x′000002′, and DB2RES23
requires an S lock. At this point, having identified the plans and resources that
are in contention, one course of action may be to ensure that the two plans,
REVP11 and REVP22, run serially against each other to avoid deadlocking. You
may be precluded from doing that, however, for operational reasons. Therefore
you must find the specific cause of the problem and resolve it.

LOCATION: ST11DB2F DB2 PERFORMANCE MONITOR (V4)
GROUP: N/P LOCKING TRACE - LOCKOUT
SUBSYSTEM: DB2F
DB2 VERSION: V4 SCOPE: MEMBER
PRIMAUTH CORRNAME CONNTYPE
ORIGAUTH CORRNMBR INSTANCE EVENT TIMESTAMP
PLANNAME CONNECT RELATED TIMESTAMP EVENT
------------------------------ ----------------- --------
DB2RES2 DB2RES23 TSO 09:59:16.37412350 DEADLOCK
DB2RES2 ¢BLANK¢ AB3F8D811B39 N/P
REVP11 BATCH
LOCK RESOURCE
TYPE NAME EVENT SPECIFIC DATA

--------- ----------------- --------------------------------------
COUNTER = 2 WAITERS = 2
TSTAMP =06/20/95 09:59:16.35
DATAPAGE DB =DB2D0005 HASH =X¢010A0308¢
OB =DB2TS005 ---------------- HOLDER --------------
PAGE=X¢000002¢ LUW=.USIBMSST11
MEMBER =N/P CONNECT =BATCH
PLANNAME=REVP11 CORRNAME=DB2RES23
---------------- WAITER --------------
LUW=.USIBMSST11
DURATION=MANUAL CORRNMBR=¢BLANK¢
DATAPAGE DB =DB2D0001 HASH =X¢01070305¢

OB =DB2TS001 ---------------- HOLDER --------------
PAGE=X¢000002¢ LUW=.USIBMSST11
---------------- WAITER ----------------

LUW=.USIBMSST11
DURATION=MANUAL CORRNMBR=¢BLANK¢
LOCKING TRACE COMPLETE
Figure 112. Lockout Trace: Locking Problem
156 DB2 PM
More detailed and specific trace information is now required for further analysis.
The SQL report set provides information about the SQL statements being issued
and the order in which they occur, along with a variety of other SQL- related
details. To produce an SQL trace, you must collect trace data. Configure
another Collect Data Report task for the SQL report set, ensuring that you use
the two plan names, REVP11 and REVP22, as a filter to reduce the trace data
collected. It is at this level of trace data collection that many records can be
written, and all attempts to narrow the focus of the data collection for specific
plans or primauths, for example, can only be beneficial in terms of cost.
Running an SQL trace, summarized by occurrence and ordered by time stamp,

shows the SQL statements processed for a plan in the order in which they were
executed. The information shows that for TRACE # 1.1, related to plan REVP22,
an update related to STMT 19 and a select related to STMT 24 occur, resulting in
a -911 being issued against the select statement and the unit of work being
rolled back. TRACE # 1.2 for plan REVP11 indicates that an update ( STMT 19 )
and a select ( STMT 24 ), which is successful, occur. Identification of the STMT
(SQL statement) syntax will reveal precisely what each plan is doing. You can
obtain this information from the DB2 SYSIBM.SYSSTMT catalog table or by
running explain against the two plans.

SQL ACTIVITY - TRACE
SUMMARIZED BY OCCURRENCE
PRIMAUTH: DB2RES2 CONNECT : BATCH
TRACE # 1.1 ORIGAUTH: DB2RES2 PLANNAME: REVP22
EVENT TIMESTAMP AET/EVENT TCB/EVENT

-------------------- ----------- ----------- --------- -----------
DBRM REVP22
UPDATE 01:12:26.62 20.668966 2.813778 STMT# 19
SELECT 01:12:47.29 7.092277 0.006173 STMT# 24
ROLLBACK 01:12:54.38 0.005351 0.001019
OTHER 01:12:54.38 STMT# 24
DETAIL
----------------------------------------------------------
REVP22
STMT# 19 ISO(CS) SQLSTATE: 00000 SQLCODE: 0
STMT# 24 ISO(CS) SQLSTATE: 57033 SQLCODE: -913
STMT# 24 SQLSTATE: 40001 SQLCODE: -911
SUMMARIZED BY OCCURRENCE
PRIMAUTH: DB2RES2 CONNECT : BATCH
TRACE # 1.2 ORIGAUTH: DB2RES2 PLANNAME: REVP11
EVENT TIMESTAMP AET/EVENT TCB/EVENT

-------------------- ----------- ----------- --------- -----------
DBRM REVP11
UPDATE 01:12:26.64 13.091934 4.025266 STMT# 19
SELECT 01:12:39.74 14.649566 0.002769 STMT# 24
DETAIL
----------------------------------------------------------
REVP11
Figure 113. SQL Trace Summarized by Occurrence: Locking Problem
Select option 10, Explain, from the DB2 PM Online Monitor Main Menu to display
the Explain Menu (see Figure 114 on page 159). Select option 3, Explain a
DBRM′s SQL statement, from the Explain Menu to display the SQL Statement
List panel (see Figure 115 on page 159).
158 DB2 PM
Explain Menu
Command ===> __________________________________________________________ __
_
Local Location . . . . : ST11DB2F DB2F V4

Current Server . . . . : ST11DB2F DB2F V4
Change current server if required, then select one of the following.
3 1. Explain an existing entry in the plan table

2. Explain a package¢s SQL statement
3. Explain a DBRM¢s SQL statement
4. Enter an SQL statement to be explained
Current Server . . . . . ST11DB2F

Current SQLID . . . . . . DB2RES2
Figure 114. Explain Menu: Locking Problem
Figure 115 and Figure 116 on page 160 show the SQL statement number
(reported as STMT in the SQL trace in Figure 113 on page 158) and the SQL
statement text. You can see that plans REVP22 and REVP11 are accessing the
same two tables but in reverse order, and that the modes of the locks taken are
incompatible when used in this context. REVP22 takes an X lock on page 2 of
DB2RES2.COLBABY1 and attempts to get an S lock on DB2RES2.COLBABY5 at
the same time as plan REVP11 obtains an X lock for update on
DB2RES2.COLBABY5 and attempts to get an S lock on DB2RES2.COLBABY1.
Hence the deadlock.
SQL Statement List ROW 1 TO 3 OF 3

Command ===> _____________________________________________________________
_

DBRM . : REVP22 Plan Name . . . . . . . . : REVP22
Statement SQL Text

_ 5 WHENEVER SQLERROR GOTO ERROUT
_ 19 UPDATE DB2RES2 . COLBABY1 SET TBCREATOR = ¢BRO

OM¢ WHERE TBNAME = ¢SYSCOPY¢
_ 24 SELECT TBCREATOR INTO :TBCREATOR FROM DB2RES2
. COLBABY5 WHERE TBNAME = ¢SYSCOPY¢
**************************** BOTTOM OF DATA *****************************
Figure 115. SQL Statement List Panel (DBRM REVP22): Locking Problem

SQL Statement List ROW 1 TO 3 OF 3
Command ===> ______________________________________________________________
_

DBRM . : REVP11 Plan Name . . . . . . . . : REVP11
Statement SQL Text

_ 5 WHENEVER SQLERROR GOTO ERROUT
_ 19 UPDATE DB2RES2 . COLBABY5 SET TBCREATOR = ¢GRO

OM¢ WHERE TBNAME = ¢SYSCOPY¢
_ 24 SELECT TBCREATOR INTO :TBCREATOR FROM DB2RES2
. COLBABY1 WHERE TBNAME = ¢SYSCOPY¢
**************************** BOTTOM OF DATA *****************************
Figure 116. SQL Statement List Panel (DBRM REVP11): Locking Problem
To resolve the deadlock situation rewrite the SQL statement, reversing the order
in which plan REVP22 accesses the two tables.
160 DB2 PM
Chapter 6. Checklists
This chapter covers most of the important fields in Accounting and Statistics. We
present in tabular form the block within Accounting or Statistics, the field name
within the block, and the identifier. We also describe the field and, where
applicable, offer some possible reasons for unexpected values as well as
recommendations for improvement.
Use the information on the checklists to become familiar with the fields and
understand in what way they are related to one another. Often by examining a
number of fields and comparing them, perhaps from multiple report sets, you
can identify the problem and its cause. you can include any other fields that are
relevant to your specific environment.

Table 5. Accounting Field 1
Report Set ACCOUNTING
Block APPL (CLASS 1)
Field Name ELAPSED TIME
Identifier ADRECETT
The elapsed time for the processing performed, which includes the time spent not only in DB2 but also in the
application. If the class 1 elapsed time is significantly less than the transaction time, analyze the IMS or CICS
monitoring information using the appropriate monitor to identify the cause. If the IMS or CICS information
does not provide an answer to the problem, you can start the performance trace and generate the SQL
activity report. The elapsed time does not include the thread creation and thread termination times or the
time before the first SQL call, so check the SQL activity report to see whether the thread creation and thread
termination times are reasonable and determine whether or not the problem is in DB2. Consider class 2
elapsed time in conjunction with this field.

Block DB2 (CLASS 2)
Field Name ELAPSED TIME
Identifier ADDB2ETT
The elapsed time for the processing performed in DB2 only. The difference between class 1 and class 2
elapsed time is the time spent outside DB2. If the difference is significant, the problem could be in the
application program, CICS, or IMS. The problem definitely is not in DB2.

Block APPL (CLASS 1)
Field Name TCB TIME
Identifier ADTCBT
The TCB time for the processing performed, which includes the time spent not only in DB2 but also in the
application. Included in this time are the following:
• SQL processing
• Synchronous I/O
• Locking (time spent requesting locks and chasing the IRLM chain)
• Latching
• Commit processing (if read-only commit, an entire commit CPU time; if update commit, a majority of
commit CPU time--more than 95%)
• Application logic (in the case of a CICS-DB2 connection does not include what is charged to the CICS
main task; it only includes subtask time).
162 DB2 PM
Block DB2 (CLASS 2)
Field Name TCB TIME
Identifier ADDBTCBT
The TCB time for the processing performed in DB2 only. The difference between class 1 TCB time and class 2
TCB time can be classified as the TCB time used for the application processing occurring outside DB2.

Block DB2 (CLASS 2)
Field Name NOT ACCOUNT.
Identifier ADNOTACC
Not accounted time in DB2. Indicates that wait time is not occurring in DB2 nor is it attributable to I/O
suspensions. Possible causes could be an incorrect dispatching priority for the transaction or MVS paging
activity. Consult an RMF report.

Block CLASS 3 SUSP.
Field Name LOCK/LATCH
Identifier QWACAWTL
The lock/latch elapsed time for suspensions. If these suspensions ultimately result in deadlocks or timeouts,
analyze the lockout trace to determine which applications are holding the locks required. For an unusually
high number of lock suspensions analyze the locking report set for information on the reason for the
suspensions and the object on which they occurred.

Block CLASS 3 SUSP.
Field Name SYNCHRON. I/O
Identifier QWACAWTI
The elapsed time spent waiting because of synchronous I/O suspensions. Large elapsed times indicate that
there may have been a change in the access path. The change in the access path and a large number of
getpages indicate the need to reorganize the data.
Chapter 6. Checklists 163

Block CLASS 3 SUSP.
Field Name OTHER READ I/O
Identifier QWACAWTR
The time spent waiting for read I/O performed by another thread. A large value indicates contention on a
busy data set, control unit, or controller. If the problem is due to an I/O bound query, use DEGREE ANY to
enable parallelism.

Block CLASS 3 SUSP.
Field Name OTHER WRITE I/O
Identifier QWACAWTW
The elapsed time spent waiting for write I/O performed under another thread. A large value indicates I/O
contention.

Block CLASS 3 SUSP.
Field Name SER.TASK SWTCH
Identifier QWACAWTE
Times reported here include waits for open/close data sets, SYSLGRNX or SYSLGRNG update, the second
phase of the two-phase commit for update threads, HSM recall for data sets, and define, extend, and delete
data set operations. The most likely cause of unexpectedly high times is the preformatting of data sets.

Block CLASS 3 SUSP.
Field Name ARC.LOG READ
Identifier QWACAWAR
The time spent waiting to read an archive log from tape. This should be a very rare occurrence as most of
the time the log data required for rollback or recovery should be available in active logs. Check to make sure
the jobs commit frequently.
164 DB2 PM
Block HIGHLIGHTS
Field Name UPDATE/COMMIT
Identifier ASIUD
The ratio of the number of updates, deletes, and inserts to the commits performed. A very large number here
can cause extended recovery time in case of a rollback.

Block SQL DML
Field Name DESCRIBE / PREPARE
Identifier QXDESC / QXPREP
The values in these two fields represent the number of describe and/or prepare statements executed.
Nonzero values indicate dynamic SQL and are normally not expected in a transaction environment.

Block LOCKING
Field Name TIMEOUTS
Identifier QTXATIM
The number of times lock suspension ultimately results in a timeout. This occurs when a requester for a lock
on a resource has waited longer than the installation-specified resource-timeout limit (ZPARM IRLMRWT).
Applications can recover from timeouts by detecting the SQL -911 return code within the application and
retrying the operation. For repeated timeouts consider serializing the activity.

Block LOCKING
Field Name DEADLOCKS
Identifier QTXADEA
Deadlocks occur when two or more application processes each hold locks on resources the others need and
without which they cannot proceed. Run the deadlock trace from statistics trace class 3 records to determine
the holders and waiters of the deadlocked resource.

Block LOCKING
Field Name ESCAL.(SHARED)
Identifier QTXALES
This field represents the number of times the locks per table(space) parameter was exceeded and the lock
was promoted from an intent share lock (IS) to a table space lock (S). This can occur, for example, in a
repeatable read application, if the maximum number of page or row locks that can be held concurrently by a
thread against a single table space for which locksize ANY was specified exceeds the ZPARM NUMLKTS
value.

Block LOCKING
Field Name ESCAL.(EXCLUSIVE)
Identifier QTXALEX
This field represents the number of times the locks per table(space) parameter was exceeded and the lock
was promoted from an intent exclusive lock (IX) to a table space lock (X). This can occur, for example, in an
update application, if the maximum number of page or row locks that can be held concurrently by a thread
against a single table space for which locksize ANY was specified exceeds the ZPARM NUMLKTS value. Lock
escalations can cause timeouts and deadlocks. Therefore examine these fields when escalations occur. Lock
escalations, shared or exclusive, should not be expected in a transaction environment.

Block RID LIST
Field Name USED
Identifier QXMIAP
A nonzero value in this field indicates that DB2 has used list prefetch activity. If you are looking at a
transaction and list prefetch is used, you may want to examine the access path used.
166 DB2 PM
Block RID LIST
Field Name FAIL-LIMIT EXC.
Identifier QXMRMIAP
The number of times RID list processing was terminated because one or more internal limits were exceeded.
If more than 25% of the rows in a table must be accessed, list prefetch is terminated and the access path
reverts to a table space scan.

Block QUERY PARALLELISM
Field Name REDUCED - NO BUFFER
Identifier QXREDGRP
The number of parallel groups executed in reduced parallel degree because of a storage shortage or
contention in the buffer pool. If this field is not zero, consider increasing the size of the buffer pool or
assigning table spaces accessed by this query to a different buffer pool.

Block QUERY PARALLELISM
Field Name SEQUENTIAL - NO BUFFER
Identifier QXDEGBUF
The number of parallel groups that fell back to sequential operation because of storage shortage or
contention in the buffer pool. Elapsed time for a query normally expected to use parallelism dramatically
increases. If this field is not zero, consider increasing the size of the buffer pool or assigning table spaces
accessed by this query to a different buffer pool.

Block BPx
Field Name SYNCHRONOUS WRITE
Identifier QBACIMW
The number of immediate writes for a page. A small value can be expected. Synchronous writes occur if
there are too many check points and/or the buffer pool is too small. If a large number of synchronous writes
occur, review the check point frequency and the size of the buffer pool.

Block BPx
Field Name SYNCHRONOUS READ
Identifier QBACRIO
The number of synchronous read I/O operations. Look for the unexpected value. For example, query-based
transactions examining many rows would be expected to use sequential prefetch, and therefore few
synchronous reads would be anticipated. An unexpected number here suggests that sequential prefetch is
disabled, or that prefetch pages are stolen from the buffer pool before they are read. Consider increasing
and/or tuning the buffer pool.

Block BPx
Field Name SEQUENTIAL PREFETCH
Identifier QBACSEQ
Transactions unexpectedly using sequential prefetch indicate a change in the access path to a table space
scan. Queries are expected to use sequential prefetch. If they do not, examine the statistics report set to
determine whether sequential prefetch is disabled. You can determine the efficiency of the buffer pool read
operations by using the buffer pool hit ratio formula:
(GETPAGES - SYNCHRONOUS READ - PAGES READ ASYNCHR) / GETPAGES
where GETPAGES is the number of GETPAGE requests.

Block BPx
Field Name HPOOL WRITES-FAILED
Identifier QBACHWF
A number of write failures indicate that there is not enough expanded storage to back the hiperpool. Issue
the DISPLAY BUFFERPOOL command; when there is a shortage of expanded storage to support the size of
the hiperpool, the value for the hiperpool ALLOCATED field is larger than the hiperpool BACKED BY ES field.
In this situation the hiperpool should be reduced.
168 DB2 PM
Block BPx
Field Name HPOOL READS FAILED
Identifier QBACHRF
A read failure means that the page is expected to be found in the hiperpool but is not found when the request
is made. A high number of read failures for the hiperpool with the CASTOUT=YES attribute indicates that
MVS is stealing a large number of pages to compensate for a shortage of expanded storage. Consider
reducing the size of the hiperpool.

Block DISTRIBUTED ACTIVITY
Field Name CONVERSATIONS QUEUED
Identifier QLACCNVQ
The number of conversation requests queued by the Distributed Data Facility and waiting for allocation.
When this value is high, you may want to increase the number of conversations by tuning VTAM.

Field Name #CONT->LIM.BL.FTCH SWCH
Identifier QLACCBLB
The number of times a switch is made from continuous to limited block fetch mode. This is applicable only for
system-directed access. Continuous block fetch is more efficient than limited block fetch. Therefore if a high
value is reported in this field, consider tuning VTAM.

Field Name MSG. IN BUFFER
Identifier QLACBROW
The number of rows sent in a block fetch buffer. A zero value in this field indicates that block fetch is not
used. You can determine the percentage of rows sent by means of block fetch by comparing the total number
of rows sent (the ROWS SENT field) with the value in this field.

Table 34. Statistics Field 1
Report Set STATISTICS
Block LOCKING
Field Name DEADLOCKS
Identifier QTXADEA
The total number of deadlocks reported. It may not be realistic to expect zero in this field. Deadlocks result
mainly because of application design problems. Ensure that all applications accessing the same tables
access them in the same sequence. Deadlocks can also occur because of type 1 index page splits in high
insert activity. Specify SUBPAGES 1 or use type 2 index.

Block LOCKING
Field Name TIMEOUTS
Identifier QTXATIM
The total number of timeouts reported. Develop a profile for this field to enable detection of upward trends or
unusual peaks.

Block LOCKING
Field Name LOCK ESCALAT(SH)
Identifier QTXALES
The number of times MAXIMUM PAGE LOCKS PER TABLE SPACE is exceeded and the table space lock
escalates from an intent share lock (IS) to a table space lock (S) for the thread. Develop a profile for this
field to enable detection of upward trends or unusual peaks.

Block LOCKING
Field Name LOCK ESCALAT(EX)
Identifier QTXALEX
The number of times MAXIMUM PAGE LOCKS PER TABLE SPACE is exceeded and the table space lock
escalates from an intent exclusive lock (IX) to a table space lock (X) for the thread. Develop a profile for this
field to enable detection of upward trends or unusual peaks.
170 DB2 PM
Block SUBSYSTEM SERVICES
Field Name QUEUED AT CREATE THREAD
Identifier Q3STCTHW
The number of create thread requests queued. Monitoring this field is useful for determining the correct
setting for the maximum number of concurrent threads (ZPARM CTHREAD). QUEUED AT CREATE THREAD
does not include DBATs. As a rule of thumb, about 1% queuing is acceptable.

Block SUBSYSTEM SERVICES
Field Name SYSTEM EVENT CHECKPOINT
Identifier QWSDCKPT
The number of checkpoints taken since DB2 startup. It is recommended that in a production environment DB2
should take checkpoints every 20 minutes or so. If you suspect that there is a problem with the frequency, on
the DB2 PM Online Monitor Statistics Detail panel type INT on the command line to start interval processing
and monitor the value over a known period of time or run a statistics report and order by interval. This, for
example, can show checkpoint activity per hour during a 24-hour period and identify whether the checkpoint
frequency should be adjusted.

Block LOG ACTIVITY
Field Name READS SATISFIED-ARCHIVE LOG
Identifier QJSTALR
The number of times DB2 must read log records and go to the archive log for the records. The value for this
ideally should be zero. For optimal performance, when data is backed out, it still should be available in the
output buffer or the active log. A large value in this field indicates that the active logs are probably too
small.

Block LOG ACTIVITY
Field Name UNAVAILABLE OUTPUT LOG BUFFERS
Identifier QJSTWTB
This field shows how many times a write request to the active log must wait because a log output buffer is
not available. You should expect a low value in this field. If these waits occur, the log output buffer is too
small, or the write threshold value is too close to the log output buffer size.

Block EDM POOL
Field Name FAILS DUE TO POOL FULL
Identifier QIESFAIL
This value should be zero. The EDM pool should be large enough to contain the cursor tables, package
tables, and database descriptors. The EDM pool also should be large enough to allow the majority of CTs,
PTs, and DBDs to remain resident within the EDM pool. This is particularly important for online transactions
that cannot afford unnecessary I/O.

Block EDM POOL
Field Name CT REQUESTS/CT NOT IN EDM
Identifier SERCTLR
This field shows the ratio of the number of requests for CT sections to the number of times CT sections not
already in the EDM pool. A value of 5 to 10 is acceptable; greater than 10 indicates greater efficiency.
Consider increasing the size of the EDM pool if the ratio is low. However, first examine the average number
of pages the EDM pool has in use and review the sizes of the CTs, PTs, and DBDs. The % EDM pages in use
should be, on average, greater that 50% and realistically approach 80% - 90%. Very large DBDs can cause
EDM pool full situations when they are loaded. You may need to consider limiting the number of table spaces
and/or indexes in a database to ensure you do not have a very large DBD.
172 DB2 PM
Block EDM POOL
Field Name PT REQUESTS/PT NOT IN EDM
Identifier SERPTLR
See CT REQUESTS/CT NOT IN EDM.

Block EDM POOL
Field Name DBD REQUESTS/DBD NOT IN EDM
Identifier SERDBLR
See CT REQUESTS/CT NOT IN EDM.

Block BPx
Field Name PAGES WRITTEN PER WRITE I/O
Identifier SBRPWWIO
There are no absolute values for this field because each installation′s workload is a special case. To assess
and detect problems with write efficiency, monitor for overall trends rather than for absolute values. The
following factors affect the ratio of pages written per write I/O: The checkpoint frequency, if too aggressive,
causes I/Os to be scheduled to write all updated pages on the deferred write queue to DASD. If this occurs
too frequently, the deferred write queue does not grow large enough to achieve a high ratio of pages written
per write I/O. The frequency of active log switches causes a system checkpoint, and the problem described
for checkpoint frequency occurs. The deferred write thresholds (VDWQT and DWQT) are a function of the
buffer pool size. If the buffer pool size is decreased, these thresholds are reached more frequently, causing
I/Os to be scheduled to write some of the pages on the deferred write queue to DASD. Because of the nature
of batch processing, the ratio of pages written to write I/Os can be expected to be higher than that expected
for transaction type workloads.

Block BPx
Field Name SYNCHRONOUS WRITES
Identifier QBSTIMW
The number of immediate writes for a page. A small value can be expected. Synchronous writes occur if
there are too many checkpoints and/or the buffer pool is too small. If a large number of synchronous writes
occur, monitor the SYSTEM EVENT CHECKPOINT field in the Subsystem Services block and the DM
THRESHOLD field in the BPx block.

Block BPx
Field Name D M THRESHOLD
Identifier QBSTDMC
A nonzero value in this field indicates severe problems with the buffer pool and that its efficiency is greatly
reduced. You may consider increasing the buffer pool. Synchronous writes will also increase if the problem
persists.

Block BPx
Field Name PREFETCH DISABLED NO BUFFER
Identifier QBSTSPD
The number of times the sequential prefetch threshold is reached. This fixed threshold is experienced if 90%
of the pages in the buffer pool are unavailable. This has an impact on large and frequent scans that use
sequential prefetch. If you are experiencing unusually high elapsed times for these types of transactions,
review the SYNCHRON. I/O (Class 3 suspensions) field in the accounting report set and examine the time.
You should see a marked increase in SYNCHRON. I/O time. Consider increasing the buffer pool size.
174 DB2 PM
Block BPx
Field Name HPOOL READ FAILED
Identifier QBSTHRF
Unsuccessful hiperpool to virtual buffer pool read, either synchronous or asynchronous. An unsuccessful read
occurs when a requested page is found in the hiperpool but its contents have been discarded by MVS. The
count does not include pages moved by the asynchronous data mover facility. For a CASTOUT=YES
hiperpool (the general case), if this number is large, the size of the hiperpool should be decreased. For
CASTOUT=NO hiperpools (used by applications that require rapid response), unsuccessful hiperpool to
virtual buffer pool read can only happen if the backing expanded storage is configured out of the system.

Block BPx
Field Name ASYN.DA.MOVER HPOOL READ-F
Identifier QBSTARF
Unsuccessful hiperpool to virtual buffer pool reads. An unsuccessful read occurs when a requested page is
found in the hiperpool but its contents have been discarded by MVS. Recommendations for CASTOUT=YES
and CASTOUT=NO are as detailed for HPOOL READ FAILED.

Block BPx
Field Name HPOOL WRITE FAILED
Identifier QBSTHWF
The number of pages for which a synchronous or asynchronous write request failed because of a shortage of
expanded storage. Backing expanded storage cannot be allocated. If the number is large, consider
decreasing the size of the hiperpool.

Block BPx
Field Name ASYN.DA.MOVER HPOOL WRITE-F
Identifier QBSTAWF
The number of pages for which write requests using the asynchronous data mover facility fail because the
backing storage has been stolen. If this number is large, consider reducing the size of the hiperpool.

Block BPx
Field Name MERGE PASS DEGRADED-LOW BUF
Identifier QBSTWFF
The number of times that a merge pass cannot be efficiently performed because of shortage of space in the
buffer pool. Consider increasing the buffer pool size.

Block BPx
Field Name WORKFILE REQ.REJCTD-LOW BUF
Identifier QBSTWFD
The number of work files (runs) that are rejected during all merge passes because of shortage of space in the
buffer pool. There are probably too many concurrent sorts in progress in conjunction with other activity in the
buffer pool. Consider dedicating a separate buffer pool for sort work files.

Block BPx
Field Name WORKFILE NOT CREATED-NO BUF
Identifier QBSTMAX
The number of times a work file is not created during sort because of buffer pool shortage.

Block BPx
Field Name PAGE-INS REQ-READ
Identifier QBSTRPI
A large value in this field indicates that the DB2 virtual buffer pool size is too large relative to available real
(central) storage. This discrepancy causes frequent page movement between expanded and central storage,
consuming CPU time. Consider using hiperpools and decreasing the size of the DB2 virtual buffer pool.
176 DB2 PM
Block BPx
Field Name PAGE-INS REQ.FOR WRT
Identifier QBSTWPI
A large value in this field indicates that the DB2 virtual buffer pool size is too large relative to available real
(central) storage. This discrepancy causes frequent page movement between expanded and central storage,
consuming CPU time. Consider using hiperpools and decreasing the size of the DB2 virtual buffer pool.

Block BPx
Field Name PREF.I/O STREAMS REDUCTION
Identifier QBSTJIS
The total number of requested I/O streams that have been denied because of a lack of buffer pool storage.
This field is applicable only for non-work-file page sets in the context of parallel query processing. For
example, if 100 prefetch I/O streams are requested and only 80 are granted, this counter contains a value 20.
Consider increasing the size of the buffer pool if this field has a nonzero value.

Block BPx
Field Name PARALL QUERY REQ.REDUCTION
Identifier QBSTPQF
The number of times that DB2 cannot allocate the requested number of buffer pages to allow a parallel group
to run to the planned degree because of a lack of buffer pool storage. This field is applicable only for
non-work-file page sets in the context of parallel query processing. Consider increasing the size of the buffer
pool if this field has a nonzero value.

Block BPx
Field Name PREF.QUANT.REDUCED TO 1/2
Identifier QBSTPL1
The number of times when the sequential prefetch quantity is reduced to one-half because of a lack of buffer
pool storage. This field is applicable only for non-work-file page sets in the context of parallel query
processing. A nonzero value here can have a serious impact on the elapsed time for parallel queries.
Consider increasing the size of the buffer pool if this field has a nonzero value.

Block BPx
Field Name PREF.QUANT.REDUCED TO 1/4
Identifier QBSTPL2
The number of times when the sequential prefetch quantity is reduced from one-half to one-quarter because
of a lack of buffer pool storage. This field is applicable only for non-work-file page sets in the context of
parallel query processing. A nonzero value here can have a serious impact on the elapsed time for parallel
queries. Consider increasing the size of the buffer pool, if this field has a nonzero value.

Block DRDA REMOTE LOCS
Field Name CONVERSATIONS QUEUED
Identifier QLSTCNVQ
The number of conversation requests queued by the Distributed Data Facility waiting for allocation. When
this value is high, you may want to increase the number of conversations by tuning VTAM.

Block DRDA REMOTE LOCS
Field Name CONT->LIM.BLOCK FETCH SWTCH
Identifier QLSTCBLB
The number of times a switch is made from continuous to limited block fetch mode. This field is applicable
only for system-directed access. Continuous block fetch is more efficient than limited block fetch. Therefore if
a large value is reported in this field, consider tuning VTAM.
178 DB2 PM
Chapter 7. Support for Distributed and Data Sharing Environments
This chapter describes the facilities that DB2 PM provides to monitor the DB2
activities in distributed and data sharing environments.
7.1 Distributed Environment

DB2 supports system-directed and application-directed access to data stored at
remote locations. In system-directed access, both the requester and the server
are DB2 for MVS. In application-directed access, the requester and the server
can be DB2 on any of the IBM platforms. Some non-DB2 subsystems also
support application server function. DB2 PM facilitates monitoring distributed
activity on DB2 for MVS subsystems.
7.1.1 DB2 PM Online Monitor

In a DB2 PM Online Monitor session, at any one time you can monitor DB2
activity at either the requester or the server.
7.1.1.1 Thread Activity

For an allied-distributed thread, you can select the Distributed Data field on the
Thread Detail panel to get to the Distributed Data window. From this window you
can progress to the Distributed Location Detail window and the Distributed
Conversation Detail window.
The Distributed Data window in combination with the Buffer Manager Activity
window and Package/DBRM window help you identify where the
allied-distributed thread time is spent.
Use the Distributed Location Detail window and the Distributed Conversation
Detail window to view the list of conversations and the details of each
conversation. These details help you determine whether there are delays in
response times and whether block fetch is used for retrieval of data.
7.1.1.2 Statistics
You can select the Distributed Data field on the DB2 Statistics Detail panel to get
a display of the Distributed Data window. From this window you can progress to
the Remote Location window.
Use the Distributed Data window to view systemwide Distributed Data Facility
(DDF) activity and examine a list of remote locations involved in the activity.
From the data displayed, you can determine how many database access threads
(DBATs) you want to support concurrently.
From the data displayed in the Remote Location window, you can determine
whether you need to tune VTAM by increasing the number of conversations.

7.1.2 DB2 PM Batch
You can use the DB2 PM Batch facilities to report distributed data. DB2 PM can
produce reports a single DB2 location or a number of different DB2 locations.
Input data sets from multiple locations can be concatenated and processed in
DB2 PM.
The reports and traces can be either nonmerged or merged. Nonmerged reports
and traces can be produced for all DB2 PM report sets. In nonmerged reports,
activity is reported in location sequence. If distributed activity takes place, the
distributed call is reported, but the work performed at the server location is not
reported. Nonmerged reports report the following for every location:
• Nondistributed transactions, that is, the allied threads at the reporting
location
• Local activity of distributed transactions originating at the reporting location,
that is, the allied-distributed threads at the reporting location without the
corresponding DBATs at other locations
• Remote activity performed at the reporting location as part of distributed
transactions originating at other locations, that is, the DBATs at the reporting
location.
In the accounting and SQL activity report sets, distributed data from multiple
locations can be merged into one report. Merged reports show distributed
activity for the requester location, that is, the allied-distributed threads at the
requester location and the corresponding DBATs at the server locations. Merged
reporting is possible only if both the requester and the server are DB2 for MVS
subsystems.
In merged reports, for a given reporting location, the following data is reported:
• Nondistributed transactions, that is, the allied threads at the reporting
location
• Both local and remote activity for distributed transactions originating at the
reporting location, that is, the allied-distributed threads from the reporting
location together with the corresponding DBATs at server locations.
You should be aware that the merged accounting and SQL activity reports are
designed to show distributed activity from the requester′s standpoint. They do
not show DBATs performed at the reporting location on behalf of other locations.
Therefore, merged reports for a server location may contain no data.
The statistics report set shows the CPU times in the DDF address space,
statistics for each remote location for system-directed access, aggregate
statistics for all locations for application-directed access, and other DDF
information not specific to the location.
The Explain report set shows information for packages bound at a remote
location. If a list of plans to be explained contains a remotely bound package,
DB2 PM Explain automatically connects to the server and explains the remote
package. Alternatively, you can specify the server location to which you want
DB2 PM Explain to connect and have the plans and packages explained.
Report Reference , IBM DATABASE 2 Performance Monitor for MVS (DB2 PM)
Version 4 Online Monitor User ′ s Guide , IBM DATABASE 2 Performance Monitor
180 DB2 PM
for MVS (DB2 PM) Version 4 Batch User ′ s Guide , and IBM DATABASE 2 for
MVS/ESA Version 4 Administration Guide for more information and examples.
7.2 Data Sharing Environment

DB2 V4 for MVS/ESA gives individual DB2 subsystems read and write access to
databases that are on shared DASD. The DB2 subsystems share the data
belonging to a data sharing group, and each subsystem is considered a member
of the group.
In a data sharing environment, you should be able to monitor the performance of

the members in a data sharing group as well as the entire group. DB2 PM
provides facilities to perform these activities.
7.2.1 DB2 PM Online Monitor

The DB2 PM Online Monitor provides information about the coupling facility locks
and the group buffer pools.
7.2.2 DB2 PM Batch

You can use DB2 PM Batch facilities to report activities in the data sharing
environment. You can produce member-specific reports in all report sets. These
reports help you monitor various aspects of performance for individual members
of a data sharing group. You can produce group-specific reports in the Audit,
Locking, Statistics, and System Parameters report sets. Group-specific reports
help you get an overall view of the performance of a data sharing group.
Information about coupling facility locks and group buffer pools is reported.
You can also produce graphs for either members only or the data sharing group.
Report Reference , IBM DATABASE 2 Performance Monitor for MVS (DB2 PM)
Version 4 Online Monitor User ′ s Guide , IBM DATABASE 2 Performance Monitor
for MVS (DB2 PM) Version 4 Batch User ′ s Guide , and IBM DATABASE 2 for
MVS/ESA Version 4 Administration Guide for more information and examples.
Chapter 7. Support for Distributed and Data Sharing Environments 181

182 DB2 PM
Appendix A. DB2 Trace Data As Input to DB2 PM Report Set
Table 65 (Page 1 of 2). DB2 PM Report Set and DB2 Trace Data
DB2 PM DB2 Trace Class Description of Class
Report Set Type
Accounting Accounting 1 Accounting data
2 In DB2 time
3 Wait time in DB2
5 Time spent processing IFI requests
7 Package information - in DB2 time
8 Package information - wait time in DB2
Audit Audit 1 Authorization failures
2 Explicit GRANT or REVOKE
3 CREATE, ALTER, and DROP operations against audited tables
4 First change of audited object
5 First read of audited object
6 SQL statement at bind
7 Change in authorization for audited object
8 Utility access to any object
I/O activity Performance 4 Buffer manager I/O and EDM pool requests
5 Log manager
21 Data sharing
Locking Statistics 3 Deadlock and timeout information
activity
Performance 4 Buffer manager I/O and EDM pool requests
6 Locking information
7 Detailed locking information
17 Drain and claim detail
20 Data sharing
21 Data sharing
Record trace All All All traces, classes, and IFCIDs can be used as input

Table 65 (Page 2 of 2). DB2 PM Report Set and DB2 Trace Data
DB2 PM DB2 Trace Class Description of Class
Report Set Type
SQL activity Accounting 1 Accounting data
2 In DB2 time
3 Wait time in DB2
5 Time spent processing IFI requests
7 Package information - in DB2 time
8 Package information - wait time in DB2
Performance 2 Subsystem related events
3 SQL-related events
4 Buffer manager I/O and EDM pool requests
8 Data manager detail
9 Sort detail
10 Autobind
13 Edit and validation exits
16 Distributed activity
Statistics Statistics 1 Statistics data
System Performance 10 Status of a buffer pool before and after an ALTER
parameters BUFFERPOOL command
Statistics 1 • System parameters that are active when a trace is started
• Buffer pool information
Accounting 1 System parameters that are active when a trace is started
Utility activity Accounting 1 Accounting data
Performance 3 SQL related events
4 Buffer manager I/O and EDM pool requests
10 Bind and utilities
13 Edit and validation exits
16 Distributed activity
184 DB2 PM
Appendix B. DB2 PM Data Sets
Table 66 and Table 67 on page 186 show the attributes that you should use in
DB2 PM version 4 for the most useful VSAM and non-VSAM data sets,
respectively.
Table 66. DB2 PM VSAM Data Sets

Data Set Key Max Min Buffer Data Index
Length Record Record Space Control Control
(bytes) Length Length (bytes) Interval Interval
(bytes) (bytes) Size Size
(bytes) (bytes)
Accounting SAVE (ACSAVDD) 216 1616 600 40960 8192 4096
Description
Stores reduced accounting data processed by the SAVE subcommand.
Statistics SAVE (STSAVDD) 92 5000 800 40960 8192 4096
Description
Stores reduced statistics data processed by the SAVE subcommand.
DISTRIBUTE (DISTDD) 158 234 234 40960 8192 4096
Description
Stores data generated by DISTRIBUTE command. The data is used as

input to produce frequency distribution graphs.
Job Summary (JSSRSDD) 52 2462 160 40960 8192 4096
Description
The job summary data set is used to save and restore related job
summary information when data is saved and restored.
Note:
1. All VSAM data sets used in a DB2 PM job must exist before the job is executed.
2. When the SAVE subcommand is specified, the save data set should be empty. If it is not empty, all
existing records are deleted.
3. Buffer space and control interval size are suggested values only. You might need to modify t h e m to suit
the requirements of your installation.

Table 67. DB2 PM Non-VSAM Data Sets
Data Set RECFM LRECL BLKSIZE Directory
Blocks
DPMPARMS FB 80 6160 5 *
Description
Stores information about changes made to DB2 PM standard
processing settings, for example, report layouts (using UTR),
time zone specifications, correlation translations, exception
field descriptions, and definition of the main packages used
in reporting. If you decide to change any DB2 PM standard
processing settings, this data set needs to be allocated.
Exception threshold (EXCPTDD) VB >=184 6223
Description
Stores information that is used for exception thresholds for
statistics and accounting field IDs. This data set is required
for all exception processing.
Exception log (EXTRCDD1) FBA 133 6251
Description
Stores a listing of accounting and statistics exception
records that identifies DB2 accounting and statistics records
with at least one field outside user-defined limits. EXTRCDD1
DD statement is required to produce the exception log data
set which is suitable for printing a report.
Exception log file (EXFILDD1) VB 512 4096
Description
This is a sequential data set suitable for use by the DB2
LOAD utility. It contains accounting and statistics exception
records similar to the listing in the exception log data set.
EXFILDD1 DD statement is required to produce the exception
log file data set.
File (ACFILDD1) (STFILDD1) (LOFILDD1) VB 9072 9076
(AUFILDD1) (AUFILDD2) (AUFILDD3)
Description
(AUFILDD4) (AUFILDD5) (AUFILDD6)
(AUFILDD7) (RTFILDD1) This data set is required when you use the FILE
subcommand. It stores unreduced data in a suitable format
for use with the LOAD utility, to be placed into DB2 tables.
You can produce reports from the data stored in these tables
using a report facility such as the IBM Query Management
Facility (QMF).
Output (DPMOUTDD) VBS 32756 6233
Description
Stores DB2 PM formatted data. Use this data set only if you
want to produce more reports from the same data later.
Note:
* You might have to increase the number of directory blocks if you intend to tailor many report layouts.
186 DB2 PM
Appendix C. Significant Exception Reporting Fields
Table 68 (Page 1 of 3). Significant Exception Reporting Fields

Scope Field ID Field Online Batch
EDM POOL QISEFAIL EDM Pool Full * *
Description
The total number of failures due to the EDM pool being full. The value should be
near zero. With any other value consider increasing the size of the EDM pool, or
look for very large DBDs as they may be the cause.
EDM POOL SERCTLR CT requests/CT not in EDM pool *
Description
The ratio reflects the proportion of CT sections that, when requested, were
already in the EDM pool. A value greater than 5 is acceptable.
EDM POOL SERPTLR PT requests/PT not in EDM pool *
Description
The ratio reflects the proportion of PT sections that, when requested, were
already in the EDM pool. A value greater than 5 is acceptable.
EDM POOL SERDBLR DBD requests/DBD not in EDM pool *
Description
The ratio reflects the proportion of DBDs that, when requested, were already in
the EDM pool. A value greater than 5 is acceptable.
BUFFER MANAGER QBSTDMC DM critical threshold reached * *
Description
When the data manager threshold is reached, GETPAGEs and RELEASEs apply to
rows instead of pages. Avoid reaching this threshold, because it has a significant
effect on performance. This field should be zero, however; if not, consider
increasing the size of the buffer pool by using the ALTER BUFFERPOOL
command.
BUFFER MANAGER QBSTXFL Buffer Pool full * *
Description
The number of times that a usable buffer could not be located in the virtual buffer
pool because the virtual buffer pool was full. Ideally this value should be zero. A
value greater than zero suggests that the buffer pool is under allocated. Use the
ALTER BUFFERPOOL command to increase the virtual buffer pool size.
BUFFER MANAGER QBSTXFV Virtual storage unavailable * *
Description
The number of virtual buffer pool or hiperpool expansion failures due to a lack of
virtual storage. Ideally this value should be zero. If not check the virtual storage
allocation of the DB2 DBM1 address space for areas that can be reduced. Check
virtual storage allocation for other buffer pools.

BUFFER MANAGER QBSTSPD Prefetch disabled/no buffer * *
Description
The number of times sequential prefetch was disabled because buffers were not
available. Ideally this value should be zero. If not consider increasing the size of
the buffer pool using the ALTER BUFFERPOOL command or reviewing the
sequential threshold. For high-use query systems reliant on prefetch consider
reducing the vertical deferred write threshold (for updated pages) and increase
the vertical sequential prefetch threshold.
BUFFER MANAGER QBSTJIS Prefetch I/O streams reduced * *
Description
The number of times requested prefetch I/O streams have been denied through
lack of virtual buffer pool space. Ideally this value should be zero. If not consider
increasing the size of the buffer pool and/or virtual pool sequential threshold
using the ALTER BUFFERPOOL command.
BUFFER MANAGER QBSTPL2 Prefetch I/O streams reduced to 1/4 * *
Description
The number of times the prefetch quantity is reduced from one-half to

one-quarter of normal. Ideally this value should be zero. If not consider
increasing the size of the buffer pool and/or virtual pool sequential threshold
using the ALTER BUFFERPOOL command.
BUFFER MANAGER QBSTRTO DFHSM recall timeouts * *
Description
The number of times DFHSM migrated table spaces or index spaces failed to be
recalled. The time is specified from the DSNTIPO panel in Recall Delay field. This
value should be close to zero; if not, consider increasing this DSNZPARM value.
When recall fails, the page set is left in a STOPPED status and remains
unavailable until it is started ACCESS(FORCE).
BUFFER MANAGER QBSTWKPD Sort/Merge Prefetch not * *
scheduled/zero quantity
Description
The number of times sequential prefetch for sort work files is not scheduled
because the prefetch quantity has been set to zero. Normally the prefetch
quantity for work files is up to a maximum of eight pages. An underallocated
buffer pool can cause this problem. Consider increasing the size of the buffer
pool or allocating a buffer pool specifically for DSNDB07 usage. This can be
especially effective with high-use query systems whose reports make extensive
use of sort activity.
DDF ACTIVITY QDSTQDBT DBATs queued - maximum active * *
Description
The number of times a DBAT was queued because it reached the DSNZPARM
maximum for active remote threads. You may want to increase the maximum
number of DBATs allowed. The maximum is specified on installation panel
DSNTIPE ′MAX REMOTE ACTIVE′.
188 DB2 PM
LOCKING QTXADEA Number of deadlocks * *
Description
The number of times a deadlock occurred. The number should be close to zero.
If locked resource type is a data page, ensure that all applications access the
resource in the same order. If deadlock is with the index with high insert activity,
ensure that subpages is set to 1. Check the commit frequency for the application;
it could be too low.
LOCKING QTXALES Lock escalation SHARE * *
Description
The number of times the maximum locks per table space is exceeded and the
table space lock escalates from page (IS) to table space (S) lock. The value
should be close to zero. In a high-use, high-availability environment, check
commit frequency to make sure commits are performed periodically. Check that
the application plan has not been bound with repeatable read.
LOCKING QTXALEX Lock escalation EXCLUSIVE * *
Description
The number of times the maximum locks per table space is exceeded and the
table space lock escalates from page (IX) to table space (X) lock. The value
should be close to zero, especially in a transaction environment. In a high-use,
high-availability environment, check commit frequency to make sure commits are
performed periodically.
LOG ACTIVITY QJSTRARH Log reads from archive log * *
Description
The number of log reads from the archive log data set. The value should be
close to zero. You should plan to be reading all log information required for
backout from active logs. With values greater than zero, either consider
increasing the size of your logs, increasing the overall number of your logs so
that wraparound time is extended, or identifying and investigating jobs causing
archive reads. These jobs may be performing mass updates, generating a great
deal of log information and committing very infrequently. If you suspected that,
use DB2 PM Batch accounting exception report to identify low update per commit
ratio.
LOG ACTIVITY QJSTWTB Output log buffers unavailable * *
Description
The number of waits caused by the output log buffers being unavailable. When
log buffers are not available, the application waits until a buffer is free. The field
should be zero. Consider increasing the number of output buffers and at the
same time increase the write threshold to generally maintain a ratio of 5 to 1 in
favor of the write threshold. Check for I/O bottlenecks on your log volumes.
Heavy logging activities coupled with I/O bottlenecks can delay the writing of
output buffers to DASD. This symptom can cause all of the buffers to fill rapidly.
Note:
* Indicates that the field is available for DB2 PM Online Monitor or DB2 PM Batch.
Appendix C. Significant Exception Reporting Fields 189

190 DB2 PM
Index
A B
access path information 54, 60 batch processing
accounting batch accounting and statistics reports 71
access path problem scenario 142 batch exception processing 31
accounting exception report 12 batch explain 58
accounting report 8 batch explain execution performance 58
accounting trace 21 batch throughput 3
accounting trace classes 8 collecting performance data 96
checklist of important fields 161 customizing DB2 PM functions 73
constrained buffer pool problem scenario 118 data sharing environment 181
default destination for trace records 69 DB2 PM batch report sets 24
FILE 43 exception processing compared to Online
graphs 26 Monitor 31
INTERVAL option 12 exception threshold data set 44
monitor trace classes 8 FILE subcommand 43
ordering by CICS transaction id 86 length of batch window 4
ordering by PACKAGE 85 reporting distributed data 180
periodic monitoring 44 buffer pool
Reduce 78 ALTER BUFFERPOOL command 122
RESTORE 79 buffer pool full 46
SAVE 26 buffer pool read hit ratio 22
SMF record type 69 buffer pool shortage 46
sort problem scenario 104 buffer pool size 17
TOP ONLY 67 buffer pool threshold 91
TOP option 12 buffer pool tuning 98
accounting by DB2 PM identifier graph 81 constrained buffer pool 119
accounting by field identifier graph 80 deferred write threshold 120
accounting long report extract DIAGNOSE command 121
access path problem scenario 143, 148 group buffer pool 56
constrained buffer pool problem scenario 120, 123 hiperpool 175
sort problem scenario 112, 115 storage problem 10
accounting TOP ONLY report 67, 90 virtual buffer pool 175
accounting TOP report 68, 75, 104, 117
active processing window 133
active threads 17, 64 C
application developer 1, 27 capacity planner 1, 27, 48, 74
audit checkpoint
audited object 183 checkpoint frequency 173
audited tables 183 SYSTEM EVENT CHECKPOINT 90
data sharing 181 CICS
default destination 69 EDM for CICS 7
FILE 43 main task 162
group-specific reports 181 monitoring information 162
performance audits for applications 7 ordering by CICS transaction id 86
report 26 ordering by CONNTYPE-PLANNAME 90
SMF record type 69 RCT table 92
authorization subtask 162
checking 70 collect report data 22, 64, 94, 149
collection dependencies 54 collect report data panel 22, 109
failure summary 40 collect task
Online Monitor 19 automatic trace triggering 65
required 54 collect performance data 70
AUTO display command 37 collect report data 22
collect task data set 96

collect task (continued) DB2 PM Non-VSAM data sets (continued)
configure 22 Exception Log File data set 186
criteria 23 Exception Threshold data set 186
data loss 71 Locking FILE data set 186
trigger automatic trace activation 65 Record Trace FILE data set 186
user-defined data set 70 Statistics FILE data set 186
command DB2 PM Online Monitor LOOK command
ALTER BUFFERPOOL 122, 184, 187 look selections menu 40
AUTO display 37 record of the exception conditions 37
DELTA 18 DB2 PM Online monitor main menu 17
DIAGNOSE 11, 54, 121 DB2 PM VSAM data dets
DISPLAY BUFFERPOOL 168 DISTRIBUTE data set 185
DISTRIBUTE 77, 185 DB2 PM VSAM data sets
EXPLAIN 134 Accounting SAVE data set 185
FILE subcommand 26, 43, 186 Job Summary data set 185
GLOBAL 69 Statistics SAVE data set 185
HISTORY command 17 DBAT (database access thread)
INTERVAL 18 maximum number allowed 188
LOOK 18, 63, 108, 130, 150 queued - maximum active 188
QUALIFY 41 queued at create thread 171
REDUCE subcommand 91 reporting location 180
RESTORE subcommand 79 server location 180
SAVE subcommand 26, 185 deadlock
SORT 41 cause 99, 166, 170
constraint information panel 57 data collector 99
correlation Identifier deadlock data panel 151
connection ID 53 event 33
CORRNAME 86 exception threshold 46
CORRNMBR 86 scenario 149
translation 86 statistics trace class 3 165
trace 25
default DDNAME
D accounting and statistics 77
data collector accounting report 78
amount of data to collect 53 accounting RESTORE 80
data space 53 accounting SAVE 78
exception condition 64 statistics report 78
EXCEPTIONEVENT parameter 19 statistics RESTORE 80
history function 52 statistics SAVE 78
periodic exception processing 19 delta processing mode 18
SDGOSAMP data set 32 DIAGNOSE
timeouts and deadlocks 99 HISTORY 17
view past data 21 diagnose function
VSAM data set 53 analyze performance data 55
data sharing environment 179, 181 DIAGNOSE command 11
database access thread Diagnosis of Thread window 56
See DBAT (database access thread) 85 invoking 56
database administrator 47, 111 recommendations 64
DB2 explain output (Table Information) 137 rules of thumb 55
DB2 explain output panel 61, 136, 145 Diagnosis of Thread window 22, 56, 122
DB2 PM data Sets Diagnosis Rules of Thumb panel 55
Non-VSAM 185 display exception processing
VSAM 185 foreground 18
DB2 PM Non-VSAM data sets invoke 18
Accounting FILE data set 186 distributed environment 29, 179
Audit FILE data set 186 DPMOUT
DPMOUT data set 186 attributes 43
DPMPARMS data set 186 cost 69
Exception Log data set 186
192 DB2 PM
DPMOUT (continued) exception thresholds (continued)
data set 18 exception threshold data set 18
DPMOUTDD 69 how profiling works 49
input to DB2 PM 43 input data used for profiling 49
record layout 43 maintain 104
DPMPARMS data set number of threshold data sets 37
MAINPACK definition 85 recommendations 71
UTR profiles 73 explain
batch explain 93
batch explain report 98
E DB2 PM Online Monitor explain 58, 143
EDM pool remote source explain 60
efficiency 90 source explain options panel 20
maximum size 114 source explain processing options 20
monitoring 48 explain menu 159
ratio 172 explain SQL statements 5
estimator 2, 4, 10
exception event detail panel 152
exception event processing F
activate 19 FILE
background 19 accounting 186
monitor 32 audit 186
exception event summary panel 32, 33, 34, 151 FILE subcommand 26
exception log locking 186
exception log (EXTRCDD1) 186 record trace 186
exception log data set 18 statistics 186
exception log file (EXFILDD1) 186 frequency distribution graph 83, 185
exception log file data set 31
view periodic exception log 63
exception processing G
background 18 graphics selection menu 76, 77
DB2 PM Online Monitor exception processing 31 graphs
display 18 accounting and statistics 26
exception event 19 accounting by DB2 PM identifier graph 81
invoke 18 accounting by field identifier graph 80
monitoring strategy 11 DISTRIBUTE command 83
passive task 31 distributed file 77
periodic 11, 18 frequency distribution graph 83
exception processor panel 19, 38, 96, 108, 149 generate and view 26
exception profiling interval and boundary 79
calculated values 51 IRF 23
DPMOUT data set as input 50 RESTORE 79
exception profiling report 50 SAVE 26
exception threshold data set 51 statistics system graph 83
panel 49 trend analysis 76
required data sets 50 GTF
exception profiling panel 50 benefit 69
exception threshold category selection panel 105, data set 8
125 input to DB2 PM 49
exception threshold data set 31, 44, 51, 107 volume of data 69
exception threshold field details panel 52, 107
exception threshold field selection panel 106, 128
exception thresholds
H
hiperpool
Batch and Online Monitor 9
CASTOUT=NO hiperpool 175
developing 11
CASTOUT=YES hiperpool 175
DPMOUT data set 50
hiperpool expansion 187
exception profiling 10
hiperpool read 55
exception profiling panel 51
hiperpool write 55
exception profiling report 51
Index 193
hiperpool (continued) locking
size of the hiperpool 169 deadlock trace 25
storage problems 10 FILE 43
virtual buffer pool 176 locking problem scenario 156
history function 52, 63 lockout trace 156
authorization 54 monitor activity 25
benefit 52 report 12
HISTORY command 17 timeout trace 25
HISTORYINTERVAL 54 lockout
past events 63 deadlocks 91
scope 53 report 99
snapshot 15 timeouts 91
host variable definition window 140 trace 88
LOOK
DB2 PM Online Monitor LOOK command 18
I Look selections menu 39, 63, 109
I/O activity
buffer pool 24
report 12 M
IBM Database 2 Performance Monitor panel 16, 58, MAINPACK identifier 27, 85
104, 125 measurements 9, 10
IFCID menu
collect task 70 DB2 PM Online Monitor Main Menu 17
configure DB2 traces 70 explain menu 159
IFCID 105 152 graphics selection 77
IFCID 172 152 look selections 40, 109, 130, 150
IFCID 196 152 merged reporting 180
IFCID 63 111 monitoring frequency 7, 67
IFCID 95 111
IFCID 96 111
IFCID selection window 154 N
IFCID selection window 154 network specialist 1, 28
IMS nonmerged reporting 180
IMS DC monitor for IMS 7
ordering by CONNTYPE-PLANNAME 90
QUALIFY command 41
O
Online Monitor
index information window 138, 145
collect data report 153
interactive report facility
delta processing mode 18
See IRF (interactive report facility) 17
HISTORY command 21
interactive report selections panel 58, 78, 79
history data 21
interval processing mode 18
history function 15
IRF (interactive report facility)
interval processing mode 18
create and execute DB2 PM commands 27
LOOK command 18, 37, 63, 150
display and print graphs 17
periodic exception processing 11
maintain parameter data sets 17
QUALIFY 41
user-tailored reporting 72
SORT 41
operations personnel 1, 8, 28, 71
K
key column information window 138
key column selection window 146
P
PACKAGE identifier 85
panel
L collect report data 110
LAYOUT option constraint information 57
customize DB2 PM report layout 16 DB2 explain output 136, 137, 139, 144, 147
customize DB2 PM trace layout 16 diagnosis rules of thumb 55
user-tailored reporting for accounting and exception event detail 152
statistics 73 exception event summary 33, 34, 151
194 DB2 PM
panel (continued) scenarios (continued)
exception processor 19, 128, 149 class 1 elapsed time problem scenario 125
exception profiling 50 constrained buffer pool problem scenario 117
exception threshold category selection 125 locking problem scenario 149
exception threshold field details 52, 127 sort problem scenario 104
exception threshold field selection 126 structured approach to problem solving 103
interactive report selections 78 service level 3, 11, 31, 44, 47
periodic exception processor 35 SMF
source explain options 21 active 65
SQL statement list 159 continuous monitoring 69
storage sizes and connections 114 data set 8
thread detail 132, 134 dump utility 69
thread summary 42 input to DB2 PM 49
performance management 2, 9, 71 record type 100 69
performance monitoring 1, 6 record type 101 69
performance objectives 1, 9 record type 102 69
performance specialist 1, 8 SORTBY option 25
performance strategy 1 source explain options 21
periodic exception notification window 39 source explain options panel 20, 21
periodic exception processing SPUFI 3, 21
activate periodic exception 96 SQL activity
background task 35 locking problem scenario 149
exception notification window 129 report 12
Online Monitor 11 SORTBY option 25
periodic exception log 63 SUMMARIZEBY option 25
periodic exception messages 40 trace 149
periodic exceptions list window 41 SQL statement and package window 20, 134, 135
road map 12 SQL statement list panel 159
periodic exception processor panel 35 statistics
periodic exceptions list window 41, 109, 131 checklist of important fields 170
PRESORTED option 69 constrained buffer pool problem scenario 121
deadlock and timeout trace 165
default destination for trace records 69
Q delta processing 18
QMF (Query Management Facility) distributed data 180
query (SQL format) 24 exception report 12
retrieve data 9 exception threshold 18
stored QMF query 58 FILE 9
Query Management Facility frequency distribution 26
See QMF (Query Management Facility) 24 interval processing 18
reduce 77
report 8
R RESTORE 79
record trace 23, 43, 78, 183
SAVE 26, 77
REDUCE processing
SMF record type 69
accounting 80
sort problem scenario 113
REDUCE subcommand 91
system graph 83
statistics 80
trace 27
RUNSTATS 4, 93, 138, 145
trace classes 8
statistics long report extract
constrained buffer pool problem scenario 121, 124
S sort problem scenario 113, 116
SAVE data set
statistics system graph 83
accounting 185
storage sizes and connections 114
statistics 185
SUMMARIZEBY option 25
VSAM 79
system parameters report 181
save-file utility 26
systems analysts 8, 9
scenarios
access path problem scenario 141
Index 195
systems p r o g r a m m e r 1, 65
T
table information window 60, 137
thread detail panel 40, 52, 132, 179
instrumentation data 53
thread summary panel 17, 42
time zone 27, 86
timeout
cause 100, 166
SQL -911 165
trace 25
trace configuration window 110, 153
trigger immediately window 111, 155
U
user-tailored reporting (UTR)
See UTR (user-tailored reporting) 72
utility activity
information about bind activity 24
information about utility execution 24
report 24
UTR (user-tailored reporting)
accounting report 72
accounting trace 72
statistics report 72
statistics trace 72
W
window
active processing 133
diagnosis of thread 22, 56, 122, 133
exception notification 129, 150
host variable definition 140
IFCID selection 154
index information 138, 145
key column information 138
key column selection 146
periodic exception notification 39
periodic exceptions list 41, 109, 131
SQL statement and package 135
table information 137, 144
trace configuration 110, 153
trigger immediately 111, 155
workload 3, 7, 44
196 DB2 PM
ITSO Technical Bulletin Evaluation RED000
October 1995
Publication No. SG24-2584-00
Your feedback is very important to help us maintain the quality of ITSO Bulletins. Please fill out this
questionnaire and return it using one of the following methods:
• Mail it to the address on the back (postage paid in U.S. only)
• Give it to an IBM marketing representative for mailing
• Fax it to: Your International Access Code + 1 914 432 8246
• Send a note to REDBOOK@VNET.IBM.COM
Please rate on a scale of 1 to 5 the subjects below.

(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction ____
Organization of the book ____ Grammar/punctuation/spelling ____

Accuracy of the information ____ Ease of reading and understanding ____
Relevance of the information ____ Ease of finding information ____
Completeness of the information ____ Level of technical detail ____
Value of illustrations ____ Print quality ____
Please answer the following questions:

a) If you are an employee of IBM or its subsidiaries:
Do you provide billable services for 20% or more of your time? Yes ____ No ____
Are you in a Services Organization? Yes ____ No ____
b) Are you working in the USA? Yes ____ No ____
c) Was the Bulletin published in time for your needs? Yes ____ No ____
d) Did this Bulletin meet your needs? Yes ____ No ____
If no, please explain:
What other topics would you like to see in this Bulletin?
What other Technical Bulletins would you like to see published?
Comments/Suggestions: ( THANK YOU FOR YOUR FEEDBACK! )
Name Address
Company or Organization
Phone No.
ITSO Technical Bulletin Evaluation
SG24-2584-00
RED000
IBML 
Fold and Tape Please do not staple Fold and Tape
NO POSTAGE
NECESSARY
IF MAILED IN THE
UNITED STATES
BUSINESS REPLY MAIL

FIRST CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK
POSTAGE WILL BE PAID BY ADDRESSEE
IBM International Technical Support Organization

Department 471, Building 070B
5600 COTTLE ROAD
SAN JOSE CA
USA 95193-0001
Fold and Tape Please do not staple Fold and Tape
SG24-2584-00
IBML 
Printed in U.S.A.
SG24-2584-00
Artwork Definitions
id File Page References
ITSLOGO 2584SU
i i
Table Definitions
HEAD1 2584CH03
46 46
MAIN 2584CH03
46 46
HEAD2 2584CH03
48 48
MAIN2 2584CH03
48 48
HD1 2584CH04
86 86
RW1 2584CH04
86 86, 86
RW2 2584CH04
86 86
RW3 2584CH04
86 86
CHK 2584CH06
162 162, 162, 162, 162, 163, 163, 163, 163, 164, 164, 164,
164, 165, 165, 165, 165, 166, 166, 166, 167, 167, 167,
167, 168, 168, 168, 169, 169, 169, 170, 170, 170, 170,
170, 171, 171, 171, 172, 172, 172, 173, 173, 173, 174,
174, 174, 175, 175, 175, 175, 176, 176, 176, 176, 177,
177, 177, 178, 178, 178
HD01 2584APXA
183 183
ROW1 2584APXA
183 183
ROW2 2584APXA
183 183
ROW3 2584APXA
183 183
ROW44 2584APXA
183 183
ROW4 2584APXA
183 184
ROW 2584APXA
183 183, 184
ROW5 2584APXA
183 184
ROW6 2584APXA
183 184
HD0A 2584APXB
185 185
ROWA 2584APXB
185 185, 185, 185, 185
HD02 2584APXB
186 186
ROWB 2584APXB
186 186, 186, 186, 186, 186, 186
HEADA 2584APXC
187 187
MAINA 2584APXC
187 187
Figures
CH01F01 2584CH01
5 1
4
CH01F02 2584CH01
12 2
11
CH01F03 2584CH01
12 3
12
CH01F04 2584CH01
13 4
13
CH02F01 2584CH02
16 5
16
CH02F02 2584CH02
17 6
16, 20, 22
CH02F03 2584CH02
19 7
18, 18
CH02F04 2584CH02
21 8
20
CH02F05 2584CH02
22 9
22
CH03F01 2584CH03
33 10
32
CH03FA1 2584CH03
34 11
33
CH03F02 2584CH03
35 12
35, 36, 38
CH03F03 2584CH03
36 13
36, 37
CH03F06 2584CH03
39 14
38
CH03F07 2584CH03
40 15
39
CH03F08 2584CH03
41 16
40, 63
CH03F09 2584CH03
42 17
41, 42
CH03F10 2584CH03
50 18
50
CH03F11 2584CH03
51 19
50
CH03F12 2584CH03
52 20
45, 51, 51
CH03F13 2584CH03
55 21
55
CH03F14 2584CH03
56 22
56
CH03F15 2584CH03
57 23
57
CH03FLO 2584CH03
62 24
61
CH04F01 2584CH04
72 25
72
CH04F03 2584CH04
73 26
73
CH04F04 2584CH04
74 27
73
CH04T02 2584CH04
74 28
74
CH04F05 2584CH04
75 29
74
CH04T01 2584CH04
75 30
75
CH04F18 2584CH04
76 31
75
CH04F06 2584CH04
77 32
76
CH04F07 2584CH04
78 33
77, 78
CH04F08 2584CH04
78 34
78
CH04F09 2584CH04
80 35
79
CH04F10 2584CH04
81 36
80
CH04F11 2584CH04
82 37
81, 81
CH04F1A 2584CH04
82 38
81, 82
CH04F12 2584CH04
83 39
83
CH04F13 2584CH04
84 40
83
CH04FFD 2584CH04
85 41
84
CH04FLO 2584CH04
87 42
86
CH04TR1 2584CH04
88 43
88
CH04F15 2584CH04
90 44
90
CH04F14 2584CH04
91 45
91
CH04F16 2584CH04
92 46
91
CH04F17 2584CH04
93 47
92
CH04E20 2584CH04
93 48
93
CH04F20 2584CH04
94 49
94
CH04F21 2584CH04
95 50
95
CH04F22 2584CH04
96 51
95
CH04F23 2584CH04
97 52
96, 97
CH04F24 2584CH04
99 53
99
CH04ST1 2584CH04
101 54
97, 100
CH05FAT 2584CH05
104 55
104
CH05FAA 2584CH05
105 56
104
CH05FAB 2584CH05
106 57
105
CH05F01 2584CH05
107 58
106, 107
CH05F02 2584CH05
108 59
107
CH05D0Z 2584CH05
109 60
108
CH05F03 2584CH05
109 61
109
CH05F04 2584CH05
110 62
110
CH05F4A 2584CH05
110 63
110
CH05F05 2584CH05
111 64
111
CH05F06 2584CH05
112 65
111, 116
CH05F07 2584CH05
113 66
112
CH05F7A 2584CH05
114 67
113
CH05F09 2584CH05
115 68
114, 116
CH05F10 2584CH05
116 69
114, 116
CH05F11 2584CH05
118 70
117, 117
CH05F12 2584CH05
119 71
117, 118
CH05F13 2584CH05
120 72
119, 122
CH05F14 2584CH05
121 73
120, 120, 123
CH05F15 2584CH05
122 74
121
CH05F16 2584CH05
123 75
122
CH05F17 2584CH05
124 76
123, 123
CH05H01 2584CH05
125 77
125, 128
CH05H1A 2584CH05
126 78
126, 128
CH05H02 2584CH05
127 79
126
CH05H03 2584CH05
128 80
128
CH05H04 2584CH05
129 81
129
CH05D0X 2584CH05
130 82
130
CH05H05 2584CH05
131 83
130
CH05H06 2584CH05
132 84
132
CH05H07 2584CH05
133 85
133
CH05H08 2584CH05
133 86
133
CH05H09 2584CH05
134 87
134
CH05H10 2584CH05
135 88
134
CH05H11 2584CH05
136 89
135
CH05H12 2584CH05
137 90
136
CH05H13 2584CH05
137 91
137
CH05H14 2584CH05
138 92
138, 138
CH05H15 2584CH05
138 93
138
CH05H16 2584CH05
139 94
139
CH05H17 2584CH05
140 95
139
CH05E01 2584CH05
142 96
141
CH05E02 2584CH05
143 97
142
CH05E03 2584CH05
144 98
143, 145
CH05E04 2584CH05
144 99
144
CH05E06 2584CH05
145 100
145
CH05E09 2584CH05
146 101
145
CH05E08 2584CH05
147 102
146
CH05E10 2584CH05
148 103
147
CH05D0W 2584CH05
149 104
149
CH05D01 2584CH05
150 105
149
CH05D0Y 2584CH05
150 106
150
CH05D02 2584CH05
151 107
151
CH05D04 2584CH05
152 108
151
CH05D05 2584CH05
153 109
CH05D06 2584CH05
154 110
153
CH05D07 2584CH05
155 111
154
CH05D08 2584CH05
156 112
155
CH05D09 2584CH05
158 113
159
CH05D10 2584CH05
159 114
158
CH05D11 2584CH05
159 115
158, 159
CH05D12 2584CH05
160 116
159
Headings
NOTICES 2584FM
xv Special Notices
ii
BIBL 2584PREF
xviii Related Publications
CH01 2584CH01
1 Chapter 1, Performance Management
xvii
MANPERF 2584CH01
1 1.1, Managing DB2 Performance
CH01S01 2584CH01
6 1.2, Developing a Monitoring Policy
CH02 2584CH02
15 Chapter 2, DB2 P M Monitoring Facilities
xvii
ONLINE 2584CH02
15 2.1, DB2 PM Online Monitor
EXCEPT 2584CH02
18 2.2, Exception Processing
EXPLAIN 2584CH02
20 2.3, Explain
HISTORY 2584CH02
21 2.4, HISTORY Command
DIAGNOS 2584CH02
21 2.5, DIAGNOSE Command
COLRDAT 2584CH02
22 2.6, Collect Report Data
BATH 2584CH02
23 2.7, DB2 PM Batch
GRAPH 2584CH02
26 2.7.4, Graphs
IRF 2584CH02
27 2.8, Interactive Report Facility
CH03 2584CH03
31 Chapter 3, Using DB2 P M for Exception Processing
xvii, 7
ACTEXP 2584CH03
38 3.2, Activating the Exception Processor
96
SETX 2584CH03
44 3.6, Setting Exception Thresholds
71
CH03S02 2584CH03
45 3.6.3, Fields for Populating the Threshold Data Set
90
SYSPROG 2584CH03
46 3.6.3.1, The System Programmer
68
DBA 2584CH03
47 3.6.3.2, The Database Administrator
68
PROFIL 2584CH03
49 3.7, Exception Profiling
10, 44
COLDAT 2584CH03
52 3.8.1, Collecting Data
54
DEPS 2584CH03
54 3.8.3, Collection Dependencies
65
PERCON 2584CH03
59 3.10.2.1, Performance Considerations
59
CH04 2584CH04
67 Chapter 4, Using DB2 P M for Periodic Monitoring
xvii
BEDONE 2584CH04
67 4.1, Monitoring Frequency
COLLECT 2584CH04
68 4.3, Collecting DB2 Performance Data
9, 68
ACTION 2584CH04
86 4.11, Solving Periodic Exceptions Using DB2 PM
CH05 2584CH05
103 Chapter 5, Scenarios
xvii
SORT 2584CH05
104 5.1, Sort Problem
147
CH06 2584CH06
161 Chapter 6, Checklists
xvii
CH07 2584CH07
179 Chapter 7, Support for Distributed and Data Sharing
Environments
xvii
CH07DIS 2584CH07
179 7.1, Distributed Environment
CH07DPM 2584CH07
179 7.1.1, DB2 PM Online Monitor
CH07DPB 2584CH07
180 7.1.2, DB2 PM Batch
CH07DSH 2584CH07
181 7.2, Data Sharing Environment
CH07DSM 2584CH07
181 7.2.1, DB2 PM Online Monitor
CH07DSB 2584CH07
181 7.2.2, DB2 PM Batch
APPXA 2584APXA
183 Appendix A, DB2 Trace Data A s Input to DB2 P M Report Set
xvii, 23
APPXB 2584APXB
185 Appendix B, DB2 P M Data Sets
xvii, 43, 43, 45, 77
APPXC 2584APXC
187 Appendix C, Significant Exception Reporting Fields
xviii, 45
Spots
LEVEL 2584CH03
52 (no text)
Tables
CH02T01 2584CH02
15 1
15
CH03T01 2584CH03
46 2
46, 100
CH03T02 2584CH03
48 3
48, 100
CORR 2584CH04
86 4
CHK01 2584CH06
162 5
CHK02 2584CH06
162 6
CHK03 2584CH06
162 7
CHK04 2584CH06
163 8
CHK05 2584CH06
163 9
CHK06 2584CH06
163 10
CHK07 2584CH06
163 11
CHK08 2584CH06
164 12
CHK09 2584CH06
164 13
CHK10 2584CH06
164 14
CHK11 2584CH06
164 15
CHK12 2584CH06
165 16
CHK13 2584CH06
165 17
CHK14 2584CH06
165 18
CHK15 2584CH06
165 19
CHK16 2584CH06
166 20
CHK17 2584CH06
166 21
CHK18 2584CH06
166 22
CHK19 2584CH06
167 23
CHK20 2584CH06
167 24
CHK21 2584CH06
167 25
CHK22 2584CH06
167 26
CHK23 2584CH06
168 27
CHK24 2584CH06
168 28
CHK25 2584CH06
168 29
CHK26 2584CH06
169 30
CHK27 2584CH06
169 31
CHK28 2584CH06
169 32
CHK29 2584CH06
169 33
CHK30 2584CH06
170 34
CHK31 2584CH06
170 35
CHK32 2584CH06
170 36
CHK33 2584CH06
170 37
CHK34 2584CH06
171 38
CHK35 2584CH06
171 39
CHK36 2584CH06
171 40
CHK37 2584CH06
172 41
CHK38 2584CH06
172 42
CHK39 2584CH06
172 43
CHK40 2584CH06
173 44
CHK41 2584CH06
173 45
CHK42 2584CH06
173 46
CHK43 2584CH06
174 47
CHK44 2584CH06
174 48
CHK45 2584CH06
174 49
CHK46 2584CH06
175 50
CHK47 2584CH06
175 51
CHK48 2584CH06
175 52
CHK49 2584CH06
175 53
CHK50 2584CH06
176 54
CHK51 2584CH06
176 55
CHK52 2584CH06
176 56
CHK53 2584CH06
176 57
CHK54 2584CH06
177 58
CHK55 2584CH06
177 59
CHK56 2584CH06
177 60
CHK57 2584CH06
178 61
CHK58 2584CH06
178 62
CHK59 2584CH06
178 63
CHK60 2584CH06
178 64
APXBT01 2584APXA
183 65
APXC01 2584APXB
185 66
185
APXC02 2584APXB
186 67
185
Processing Options
Runtime values:
Document fileid ........................................................................................... SG242584 SCRIPT
Document type ............................................................................................ USERDOC
Document style ........................................................................................... IBMXAGD
Profile ........................................................................................................... EDFPRF30
Service Level .............................................................................................. 0029
SCRIPT/VS Release ................................................................................... 4.0.0
Date .............................................................................................................. 95.10.25
Time .............................................................................................................. 20:04:51
Device .......................................................................................................... 3820A
Number of Passes ...................................................................................... 4
Index ............................................................................................................. YES
SYSVAR D .................................................................................................... YES
SYSVAR G ................................................................................................... INLINE
SYSVAR S .................................................................................................... OFF
SYSVAR V .................................................................................................... ITSCEVAL
Formatting values used:

Annotation .................................................................................................... NO
Cross reference listing .............................................................................. YES
Cross reference head prefix only ............................................................ NO
Dialog ........................................................................................................... LABEL
Duplex .......................................................................................................... YES
DVCF conditions file ................................................................................... (none)
DVCF value 1 .............................................................................................. (none)
DVCF value 2 .............................................................................................. (none)
DVCF value 3 .............................................................................................. (none)
DVCF value 4 .............................................................................................. (none)
DVCF value 5 .............................................................................................. (none)
DVCF value 6 .............................................................................................. (none)
DVCF value 7 .............................................................................................. (none)
DVCF value 8 .............................................................................................. (none)
DVCF value 9 .............................................................................................. (none)
Explode ........................................................................................................ NO
Figure list on new page ............................................................................. YES
Figure/table number separation ............................................................... YES
Folio-by-chapter .......................................................................................... NO
Head 0 body text ........................................................................................ Part
Head 1 body text ........................................................................................ Chapter
Head 1 appendix text ................................................................................. Appendix
Hyphenation ................................................................................................ NO
Justification ................................................................................................. NO
Language ..................................................................................................... ENGL
Layout .......................................................................................................... OFF
Leader dots ................................................................................................. YES
Master index ............................................................................................... (none)
Partial TOC (maximum level) .................................................................... 4
Partial TOC (new page after) .................................................................... INLINE
Print example id′s ...................................................................................... NO
Print cross reference page numbers ....................................................... YES
Process value ............................................................................................. (none)
Punctuation move characters ................................................................... .,
Read cross-reference file .......................................................................... (none)
Running heading/footing rule .................................................................... NONE
Show index entries ..................................................................................... NO
Table of Contents (maximum level) ......................................................... 3
Table list on new page .............................................................................. YES
Title page (draft) alignment ....................................................................... RIGHT
Write cross-reference file .......................................................................... (none)
Imbed Trace
Page 0 2584SU
Page 0 2584VARS
Page 0 2584FM
Page i 2584EDNO
Page ii 2584ABST
Page xv 2584SPEC
Page xv 2584TMKS
Page xvi 2584PREF
Page xix 2584ACKS
Page xx 2584CH01
Page 13 2584CH02
Page 29 2584CH03
Page 65 2584CH04
Page 102 2584CH05
Page 160 2584CH06
Page 178 2584CH07
Page 182 2584APXA
Page 184 2584APXB
Page 186 2584APXC
Page 196 2584EVAL
Page 196 RCFADDR
Page 196 ITSCADDR FILE
Page 197 RCFADDR
Page 197 ITSCADDR FILE

DB2 PM Usage Guide Update

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DB2 PM Usage Guide Update

Uploaded by

Copyright:

Available Formats

SG24-2584-00

International Technical Support Organization

DB2 PM Usage Guide Update

DB2 PM Usage Guide Update

First Edition (October 1995)

IBM Corporation, International Technical Support Organization

 Copyright International Business Machines Corporation 1995. All rights reserved.

This document is written for system programmers, database administrators, and

 Copyright IBM Corp. 1995 iii

Chapter 1. Performance Management . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2. DB2 PM Monitoring Facilities . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 3. Using DB2 PM for Exception Processing . . . . . . . . . . . . . . . 31

 Copyright IBM Corp. 1995 v

Chapter 4. Using DB2 PM for Periodic Monitoring . . . . . . . . . . . . . . . . 67

Chapter 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Chapter 6. Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Chapter 7. Support for Distributed and Data Sharing Environments . . . . . 179

Appendix A. DB2 Trace Data As Input to DB2 PM Report Set . . . . . . . . . 183

Appendix B. DB2 PM Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Appendix C. Significant Exception Reporting Fields . . . . . . . . . . . . . . 187

1. Explain SQL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

 Copyright IBM Corp. 1995 ix

1. Monitor Trace Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

 Copyright IBM Corp. 1995 xiii

This publication is intended to help system programmers, database

References in this publication to IBM products, programs or services do not

The following terms are trademarks of the International Business Machines

The following terms are trademarks of other companies:

C-bus is a trademark of Corollary, Inc.

PC Direct is a trademark of Ziff Communications Company and is

 Copyright IBM Corp. 1995 xv

Windows is a trademark of Microsoft Corporation.

Other trademarks are trademarks of their respective companies.

This document provides information about how to monitor performance in the

This document is intended for system programmers, database administrators,

How This Document Is Organized

 Copyright IBM Corp. 1995 xvii

International Technical Support Organization Publications

A complete list of International Technical Support Organization publications, with

To get a catalog of ITSO technical publications (known as “redbooks”), VNET

A listing of all redbooks, sorted by category, may also be found on MKTTOOLS

Customers may order hardcopy ITSO books individually or in customized

ITSO Redbooks on the World Wide Web (WWW)

The authors of this document are:

Maria Sueli de Almeida

This publication is the result of a residency conducted at the International

Thanks to Akira Shibamiya of IBM Development, Santa Teresa, the consultant on

This chapter describes the elements comprising performance management, from

The delivery of information from business-critical applications is dependent on a

Although many different professionals are involved in the process of delivering

The responsibility may encompass these job families:

1.1 Managing DB2 Performance

If objectives are achieved, monitoring can be relaxed and conducted on a

If the performance objectives are not met you should:

 Copyright IBM Corp. 1995 1

The performance management process is ongoing. Extra unrelated workload,

1.1.1 Establishing Objectives

Your performance objectives should be realistic, achievable within budget

Common objectives you should consider are:

1.1.2 Service Levels

1.1.4 Initial Planning

Chapter 1. Performance Management 3

1.1.5 Internal Design

1.1.6 Coding and Testing