View
185
Download
4
Category
Tags:
Preview:
DESCRIPTION
dbacockpit db2
Citation preview
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
1/193
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
2/193
SAP DBA CockpitFlight Plans for
DB2 LUW Database Administrators
Eduardo Akisue
Jeremy Broughton
Liwen Yeow
Patrick Zeng
Foreword by Torsten Ziegler
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
3/193
SAP DBA Cockpit:Flight Plans for DB2 LUW Database Administrators
Eduardo Akisue, Jeremy Broughton, Liwen Yeow, Patrick Zeng
Foreword by Torsten ZieglerOctober 2009
2009 IBM Corporation. All rights reserved.
Portions MC Press Online, LP.
Every attempt has been made to provide correct information. However, the publisher and the author
do not guarantee the accuracy of the book and do not assume responsibility for information in-
cluded in or omitted from it.
IBM is a registered trademark of International Business Machines Corporation in the United States,
other countries, or both. DB2 is a registered trademark of International Business Machines Corpo-
ration in the United States, other countries, or both. All other product names are trademarked or
copyrighted by their respective manufacturers.
This publication is protected by copyright, and permission must be obtained from the publisher
prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by
any means, electronic, mechanical, photocopying, recording, or likewise.
For information regarding permissions or special orders, please contact:
MC Press
Corporate Offices
125 N. Woodland Trail
Lewisville, TX 75077 USA
For information regarding sales and/or customer service, please contact:
MC Press
P.O. Box 4300
Big Sandy, TX 75755-4300 USA
ISBN: 978-158347-089-3
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
4/193
About the Authors
Eduardo Akisue is a member of the WW DB2 SAP Technical
Sales Enablement and Support team. Previous to his current
role, he worked for many years supporting DB2 and Informix
customers in the Latin America region. He is a Certified DB2 9
Administrator, a Certified Informix Administrator, and an
Informix dial-up Engineer. He is also a Certified SAP Tech-
nology Consultant and an SAP Certified OS/DB Migration
Consultant. Eduardo can be reached at akisue@us.ibm.com.
Jeremy Broughton is a Technical Enablement Specialist for
IBM DB2 and SAP. He has worked within the IBM DB2 De-
velopment Lab for 10 years, first developing infrastructure and
tooling for DB2 development, and then rewriting internal DB2
code to optimize compilation performance and development
agility. For the past three years, Jeremy has been dedicated to
helping SAP professionals leverage the strengths of DB2
within SAP implementations. He has assisted with proofs of
concept, provided consulting to customers implementing SAP
on DB2, and presented numerous workshops around the world
teaching DB2 administration and migration methodology for
SAP systems. He is an SAP Certified Basis Consultant for DB2
on NetWeaver 2004, and an SAP Certified OS/DB Migration
Consultant. Jeremy can be reached at jeremyb@ca.ibm.com.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
5/193
Liwen Yeow is the WW SAP Technical Sales Manager for
DB2 Distributed Platforms. He has been with IBM since 1988
and has worked in the SAP field since 1995 in multiple capaci-ties: as part of DB2 Service, as an SAP Consultant for DB2, as
a Customer Advocate for many of the large SAP-DB2 custom-
ers, and as Manager of the IBM-SAP Integration and Support
Center. In his current role, he is responsible for the enablement
of the Technical Pre-Sales teams and provides guidance to the
Sales teams in SAP sales opportunities. He is a Certified Tech-
nology AssociateSystem Administration (DB2) for SAP
NetWeaver 7.0, and an SAP Certified Technology Consultant
for DB/OS Migration. Liwen can be reached atyeow@ca.ibm.com
Patrick Zeng was a member of the WW DB2 SAP Technical
Sales Enablement and Support team and currently works as a
DBA at Bank of America. He has many years worth of expe-
rience supporting SAP and DB2 customers. He is a Certified
DB2 Solutions Expert and a Certified SAP Technology Con-sultant. Patrick can be reached at
patrick.pucheng.zeng@gmail.com.
Torsten Ziegler has been the Development Manager for SAP
NetWeaver on IBM DB2 for Linux, UNIX, and Windows since
2001. After having worked in other industries, he joined SAP
as a developer in 1997. In his current role, he is responsible fordevelopment, maintenance, and development support for all
DB2-specific components of SAP NetWeaver and applications
based on NetWeaver. He can be reached at
torsten.ziegler@sap.com
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
6/193
Acknowledgments
The authors would like to express their gratitude for the technical contributions
received by the following colleagues:
At IBM:
Guiyun Cao
Martin Mezger
Karl Fleckenstein
At SAP AG:
Torsten Ziegler
Ralf StaufferAndreas Zimmermann
Steffen Siegmund
Britta Bachert
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
7/193
Contents
Foreword by Torsten Ziegler. . . . . . . . . . . . . . . . . . . vi
Chapter 1: The SAP DBA Cockpit . . . . . . . . . . . . . . . . . . . . . . 1
Central Monitoring of Remote Systems . . . . . . . . . . . . . . 5
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 2: Performance Monitoring . . . . . . . . . . . . . . . . . . . . . 6
Performance: Partition Overview . . . . . . . . . . . . . . . . . . 7
Performance: Database Snapshot . . . . . . . . . . . . . . . . . . 9
The Buffer Pool . . . . . . . . . . . . . . . . . . . . . . . . 10
The Catalog Cache and Package Cache . . . . . . . . . . . . 15Asynchronous I/O . . . . . . . . . . . . . . . . . . . . . . . 18
Direct I/O. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Real-Time Statistics (RTS). . . . . . . . . . . . . . . . . . . 20
Locks and Deadlocks. . . . . . . . . . . . . . . . . . . . . . 21
Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Sorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
XML Storage . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Performance: Schemas. . . . . . . . . . . . . . . . . . . . . . . 31Performance: Buffer Pool Snapshot . . . . . . . . . . . . . . . . 31
Performance: Tablespace Snapshot . . . . . . . . . . . . . . . . 33
Performance: Table Snapshot . . . . . . . . . . . . . . . . . . . 34
Performance: Application Snapshot . . . . . . . . . . . . . . . . 36
Performance: SQL Cache Snapshot . . . . . . . . . . . . . . . . 37
Performance: Lock Waits and Deadlocks . . . . . . . . . . . . . 39
i
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
8/193
Performance: Active Inplace Table Reorganizations . . . . . . . 41
Performance: HistoryDatabase . . . . . . . . . . . . . . . . . . 41
Performance: HistoryTables . . . . . . . . . . . . . . . . . . . 42
Performance Warehouse . . . . . . . . . . . . . . . . . . . . . . 43
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Chapter 3: Storage Management . . . . . . . . . . . . . . . . . . . . . . 45
Automatic Storage . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
The Technical Settings Tab . . . . . . . . . . . . . . . . . . 51
The Storage Parameters Tab . . . . . . . . . . . . . . . . . . 53
The Containers Tab . . . . . . . . . . . . . . . . . . . . . . 54DMS/SMS Table Spaces . . . . . . . . . . . . . . . . . . . . 54
Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Tables and Indexes. . . . . . . . . . . . . . . . . . . . . . . . . 57
Single Table Analysis . . . . . . . . . . . . . . . . . . . . . . . 60
The Table Tab . . . . . . . . . . . . . . . . . . . . . . . . . 61
The Indexes Tab . . . . . . . . . . . . . . . . . . . . . . . . 63
The Table Structures Tab . . . . . . . . . . . . . . . . . . . 64
The RUNSTATS Control Tab . . . . . . . . . . . . . . . . . 65
The Index Structures Tab . . . . . . . . . . . . . . . . . . . 67The RUNSTATS Profile Tab . . . . . . . . . . . . . . . . . 67
The Table Status Tab. . . . . . . . . . . . . . . . . . . . . . 67
The Compression Status Tab. . . . . . . . . . . . . . . . . . 69
Virtual Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Historical Analysis . . . . . . . . . . . . . . . . . . . . . . . . 75
The Database and Table Spaces . . . . . . . . . . . . . . . . 77
Tables and Indexes . . . . . . . . . . . . . . . . . . . . . . . 78
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Chapter 4: Job Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 81
The Central Calendar . . . . . . . . . . . . . . . . . . . . . . . 81
The DBA Planning Calendar . . . . . . . . . . . . . . . . . . . 83
REORGCHK for All Tables . . . . . . . . . . . . . . . . . . 84
Scheduling Backups . . . . . . . . . . . . . . . . . . . . . . 85
Archiving Log Files to a Tape Device . . . . . . . . . . . . . 86
ii
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
9/193
Updating Statistics . . . . . . . . . . . . . . . . . . . . . . . 86
Table Reorganization. . . . . . . . . . . . . . . . . . . . . . 87
Custom Job Scripts . . . . . . . . . . . . . . . . . . . . . . . 87
The DBA Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Back-end Configuration . . . . . . . . . . . . . . . . . . . . . . 89
SQL Script Maintenance. . . . . . . . . . . . . . . . . . . . . . 90
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Chapter 5: Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . 92
The Backup Strategy. . . . . . . . . . . . . . . . . . . . . . . . 93
Utility Throttling. . . . . . . . . . . . . . . . . . . . . . . . . . 94
Scheduling Backups in the DBA Cockpit . . . . . . . . . . . . . 95Multi-partition Databases . . . . . . . . . . . . . . . . . . . 99
Advanced Backup Technology . . . . . . . . . . . . . . . . 100
The DB2 Recovery History File . . . . . . . . . . . . . . . 100
The Backup and Recovery Overview Screen . . . . . . . . . . 102
The Database Backup Tab . . . . . . . . . . . . . . . . . . 102
The Archived Log Files Tab . . . . . . . . . . . . . . . . . 102
Logging Parameters . . . . . . . . . . . . . . . . . . . . . . . 103
The Log Directory . . . . . . . . . . . . . . . . . . . . . . 104
The ARCHMETH1 Tab . . . . . . . . . . . . . . . . . . . 105Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Chapter 6: Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 106
The Overview Screen. . . . . . . . . . . . . . . . . . . . . . . 108
The Database Manager . . . . . . . . . . . . . . . . . . . . . . 109
The Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Registry Variables . . . . . . . . . . . . . . . . . . . . . . . . 117
Environment Variables . . . . . . . . . . . . . . . . . . . . 118
Registry Variables . . . . . . . . . . . . . . . . . . . . . . 118Parameter Changes . . . . . . . . . . . . . . . . . . . . . . . . 121
Database Partition Groups . . . . . . . . . . . . . . . . . . . . 122
Buffer Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Special Tables Regarding RUNSTATS . . . . . . . . . . . . . 125
File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Data Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
iii
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
10/193
Monitoring Settings . . . . . . . . . . . . . . . . . . . . . . . 128
Automatic Maintenance Settings . . . . . . . . . . . . . . . . . 130
Automatic Backups . . . . . . . . . . . . . . . . . . . . . . 130
Automatic RUNSTATS. . . . . . . . . . . . . . . . . . . . 131
Automatic REORG . . . . . . . . . . . . . . . . . . . . . . 132
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Chapter 7: The Alert Monitor . . . . . . . . . . . . . . . . . . . . . . . . 135
The Alert Monitor. . . . . . . . . . . . . . . . . . . . . . . 136
The Alert Message Log . . . . . . . . . . . . . . . . . . . . 137
Alert Configuration . . . . . . . . . . . . . . . . . . . . . . 138
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Chapter 8: Database Diagnostics . . . . . . . . . . . . . . . . . . . . . 140
The Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . 141
The EXPLAIN Option . . . . . . . . . . . . . . . . . . . . . . 142
The New Version of EXPLAIN . . . . . . . . . . . . . . . . . 146
Missing Tables and Indexes . . . . . . . . . . . . . . . . . . . 147
The Deadlock Monitor . . . . . . . . . . . . . . . . . . . . . . 149
Creating the Deadlock Monitor . . . . . . . . . . . . . . . 151
Enabling the Deadlock Monitor . . . . . . . . . . . . . . . 151Analyzing the Information Collected . . . . . . . . . . . . . 151
Stopping the Deadlock Monitor . . . . . . . . . . . . . . . 154
Resetting or Dropping the Deadlock Monitor . . . . . . . . 154
The SQL Command Line. . . . . . . . . . . . . . . . . . . . . 154
The Index Advisor . . . . . . . . . . . . . . . . . . . . . . . . 156
Indexes Recommended by DB2 . . . . . . . . . . . . . . . 157
Creating Virtual Indexes . . . . . . . . . . . . . . . . . . . 157
The Cumulative SQL Trace . . . . . . . . . . . . . . . . . . . 159
The DBSL Trace Directory. . . . . . . . . . . . . . . . . . . . 161The Sequential DBSL Trace . . . . . . . . . . . . . . . . . 161
The Deadlock Trace. . . . . . . . . . . . . . . . . . . . . . 162
Trace Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
The Database Notification Log. . . . . . . . . . . . . . . . . . 165
The Database Diagnostic Log . . . . . . . . . . . . . . . . . . 166
DB2 Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
iv
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
11/193
The Dump Directory . . . . . . . . . . . . . . . . . . . . . . . 168
The DB2 Help Center . . . . . . . . . . . . . . . . . . . . . . 169
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Chapter 9: New Features . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Workload Management (WLM) . . . . . . . . . . . . . . . . . 171
Workloads and Service Classes. . . . . . . . . . . . . . . . 172
Critical Activities . . . . . . . . . . . . . . . . . . . . . . . 173
BI Administration . . . . . . . . . . . . . . . . . . . . . . . . 174
BI Data Distribution . . . . . . . . . . . . . . . . . . . . . 174
The MDC Advisor . . . . . . . . . . . . . . . . . . . . . . 176
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
v
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
12/193
Foreword
This is a remarkable book, written by IBM experts who have in-depth knowledge
about SAP on DB2. The authors have their profound experience not only from
their work with many customers who adopted DB2 for their SAP applications,
but also from their very close cooperation with SAP development. Based on the
analogy of a pilots need to know about the controls of his aircraft, this book
takes you through the entire world of DB2 monitoring and administration. You
will find it a useful introduction if you are new to SAP on DB2, and you will also
be able to use it as a reference if you are an experienced DBA.
The SAP DBA Cockpit is one of many visible proof points of the excellent inte-
gration of SAP solutions with IBM DB2. This book will familiarize you with ev-
erything you need to know to operate IBM DB2 optimally with your SAPsolution. In a tutorial-like, easy to read style it takes you from the basic controls
to advanced monitoring and tuning, and at the same time provides you with use-
ful background information about DB2. And even more, it is just fun to read.
I hope you will find it as useful and enjoyable as I did.
Torsten Ziegler
SAP Manager
DB2 LUW Platform Development
vi
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
13/193
Chapter 1
The SAP DBA Cockpit
A Pilot Must Know the Controls
Like a pilot must know the aircraft cockpit, a databaseadministrator must know the SAP database administration
tools. The SAP DBA Cockpit is the central databaseadministration interface for SAP systems on all databases.
The DBA Cockpit for DB2 provides administrators
with a more comprehensive administration andmonitoring tool for SAP databases.
Piloting a large commercial aircraft requires a great deal of skill. Pilots mustunderstand how the adjustments they make to the aircraft components affectthe flight of the airplane. Balancing lift and drag, speed and altitude, yaw and
wind are all important parts of a safe, comfortable flight. However, a huge
amount of technology also operates and manages the individual aircraft compo-nents. A pilot who flew the aircraft without knowing what the technology does
could disrupt automated flight operations. Similarly, if the technology were not
leveraged specifically for the aircraft flight requirements, flight operations could
become more difficult. To ensure an efficient and comfortable flight, an adept pi-
lot must understand both the high-level operation of the aircraft and the underly-
ing technology that operates the components.
1
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
14/193
Considering the operation of the database technology within an SAP application,
administrators and pilots have similar skill requirements. Operating SAP applica-
tions without considering the optimizations within the database technology cancause inefficiencies, and configuring the database without considering the unique
SAP application workload characteristics can produce unstable, sub-optimal per-
formance results. Adept SAP administrators must understand how to best lever-
age the database technology specifically for the workloads of their SAP systems.
Traditionally, this is where administrative consoles have come up short. Database
administration consoles were too generic to focus on application-specific require-
ments, and application administration consoles were not specific enough to fully
leverage the database. SAP and IBM took huge steps to bridge this gap, though,
with the development of the SAP DBA Cockpit for DB2. The result is a completegraphical interface for monitoring and administering the database, all within a
single transaction in the SAP application.
Administrators can now easily access all of the database key performance indica-
tors (KPIs) and make changes to improve system performance from within the
same dialog screens. The most important information for SAP administrators is
now at their fingertips, and the database administrative tasks can often be exe-
cuted with a few simple mouse clicks. This single DBA Cockpit interface simpli-
fies monitoring and maintenance tasks, and can reduce the overall time spent ondatabase administration.
The DBA Cockpit contains two main sections: a large detailed display on the
right, and a small navigation menu on the left. Figure 1.1 shows the System Con-
figuration screen, which is the initial dialog screen displayed by running the
DBACOCKPIT transaction. This can also be displayed at any time by clicking the
System Configuration button, just above the left navigation menu.
2
CHAPTER 1: The SAP DBA Cockpit
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
15/193
The right display window contains a list of all the database systems that are con-
figured for monitoring from the DBA Cockpit. The left navigation menu containsthe following folders for navigating into database function groups:
PerformanceDisplay performance statistics for monitoring database
memory, disk I/O, application resource usage, query execution, and more.
SpaceReview historical and real-time storage usage for table spaces,
containers, and individual tables, and perform administrative functions to
alter the logical and physical storage layout of the SAP database.
Backup and Recovery OperationsReview historical backup and log
archival information, and real-time log file system statistics.
Database ConfigurationDisplay and update database configuration
parameters, configure partition groups and buffer pools, and adjust
monitoring and automatic maintenance settings.
3
CHAPTER 1: The SAP DBA Cockpit
Figure 1.1: The SAP DBA Cockpit for DB2 has a large display area on the right and a small
navigation menu on the left.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
16/193
Job SchedulingCreate, schedule, and monitor periodic jobs from a
planning calendar.
Alert MonitoringView key database health alert statuses and messages,
and enable notification for database alert threshold violations.
Diagnostic FunctionsView and filter messages from the database
diagnostic logs, view optimizer access plans and recommended indexes for
SQL statements, run SQL commands, view DB2 online help, and more.
Workload ManagementSet up, maintain, and monitor the different
workloads and service classes configured for the SAP system in DB2s
Workload Management.
BW AdministrationChange data distribution and analyze
Multi-Dimensional Clustering in partitioned SAP NetWeaver BW
databases.
The left navigation frame of SAP Enhancement Package 1 for SAP NetWeaver
7.0 contains two additional screens. The first entry links the user directly into the
DB2 LUW main web page in the SAP Developers Network (SDN), allowing the
user to browse the SDN from directly within the SAP GUI. The other screen
launches the new web browser-based DBA Cockpit. Several of the new features
of the DBA Cockpit are now launched as WebDynpro browser applications.
When one of these is clicked in the SAP GUI-based DBA Cockpit, the corre-
sponding WebDynpro screen will automatically launch in the browser. The Start
WebDynpro GUI menu entry launches the main page of the web browser-based
DBA Cockpit, similar to the DBACOCKPIT transaction in the SAP GUI.
The contents of the left navigation menu may differ slightly among different ver-
sions of SAP BASIS, in order to leverage new functionality available in the latest
releases of SAP and DB2. This book illustrates the latest features available in the
DBA Cockpit in SAP Enhancement Package 1 for SAP NetWeaver 7.0.
4
CHAPTER 1: The SAP DBA Cockpit
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
17/193
Central Monitoring of Remote Systems
The DBA Cockpit allows administrators to configure connections to every SAPsystem from a single DBA Cockpit session. A Solution Manager instance or a
standalone SAP NetWeaver instance can be installed for administrators to use for
central monitoring and administration. You should keep this SAP system at the
most current SAP release level, to maximize backward compatibility and make
the most advanced DBA Cockpit features available for all systems.
Remote connections can be established using the database information from the
System Landscape Directory (SLD). Alternatively, they can be configured manu-
ally from within the DBA Cockpit, using the DB Connections button at the top ofthe left navigation menu. From the System Configuration screen, simply click the
SLD System Import button. This provides a graphical interface to select and reg-
ister the unregistered SAP systems into the cockpit. This allows the entire SAP
system landscape to be centrally managed in the SLD, and provides a simple way
to register any new or changed systems in your central DBA Cockpit.
Alternatively, click theAddbutton to manually register new databases into the
cockpit. This allows administrators to register even non-SAP systems. Therefore,
the DBA Cockpit can provide a single administrative GUI for every SAP and
non-SAP database in your IT landscape.
Summary
The SAP DBA Cockpit for DB2 is a powerful interface for SAP pilots to cen-
trally manage the DB2 database operations of their SAP systems. It provides a
single point of administration for every DB2 database in your organization. The
SAP DBA Cockpit for DB2 gives administrators fast and easy access to all of the
most important DB2 database information, all from within the familiar look and
feel of SAP GUI.
5
CHAPTER 1: The SAP DBA Cockpit
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
18/193
Chapter 2
Performance Monitoring
Are You Flying a Glider or a Jet?
The DBA Cockpit performance monitors providea simple interface to easily access all of the key
performance data for the DB2 database.By understanding the DBA Cockpit information
and integrating it with the other performance dataavailable within SAP, administrators can more
effectively optimize the performance of their SAP systems.
Performance tuning can be a very complicated task, involving many differentareas of the SAP application. The database is one of the key areas, and theSAP DBA Cockpit for DB2 can greatly reduce the effort of monitoring and tun-
ing it. The DBACOCKPIT transaction efficiently organizes the database perfor-
mance statistics into the following sections, containing easily accessible screens
and tabs for important, related information:
Performance: Partition Overview
Performance: Database Snapshot
Performance: Schemas
Performance: Buffer Pool Snapshot
Performance: Tablespace Snapshot
6
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
19/193
Performance: Table Snapshot
Performance: Application Snapshot
Performance: SQL Cache Snapshot
Performance: Lock Waits and Deadlocks
Performance: Active Inplace Table Reorganizations
Performance: HistoryDatabase
Performance: HistoryTables
Everything needed by a database administrator is only a click or two away.
Performance: Partition Overview
Database Partitioning Feature (DPF) is one of the key DB2 features for improv-
ing the performance of SAP NetWeaver BW systems. DPF allows a SAP
NetWeaver BW database to scale out incrementally on lower-cost hardware, or
grow massive data warehouses across multiple, large servers. The goal of data-
base partitioning is to divide the database workload evenly across multiple parti-
tions, perhaps on different physical machines, so that long-running SQL
statements can be divided and conquered. If the workload is balanced evenly
across all partitions, all then operate on an equal share of the data and processtheir intermediate results sets in about the same amount of time. This equal divi-
sion of processing minimizes the overall response time and maximizes
performance.
To access the partition overview, shown in Figure 2.1, click Performance
Partitions in the navigation frame of the DBA Cockpit. This displays the most
important performance statistics for each active partition in the current SAP
NetWeaver BW system. For each partition, this overview shows the total number
and size of the buffer pools, key I/O read and write characteristics, SQL state-ment executions, and package cache statistics. Ideally, a well-balanced system
will have similar values on each partition for all of these characteristics.
Probably the most important performance indicator is buffer pool hit ratio. This
can be calculated by comparing the number of logical and physical reads.
Alternatively, it can be displayed by double-clicking one of the partitions to view
7
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
20/193
the database snapshot data from that partition. On each partition, the index hit
ratio should be about 98 percent, and the data hit ratio should be 95 to 98 percent.
Administrators should try to balance I/O as evenly as possible across all parti-
tions in the system. The easiest way to achieve this is to distribute all large or
heavily accessed tables across all partitions. However, for very large systems
with a very high number of partitions, it might be impractical to distribute tablesthinly across all partitions. In this case, heavily accessed tables can be balanced
equally across subsets of partitions. For example, one heavily accessed InfoCube
can reside on partitions 1 through 9, and another heavily accessed InfoCube can
reside on partitions 10 through 19. The most important point is to try to keep da-
tabase size and I/O activity as balanced as possible across all partitions, so that
the database leverages the full processing capacity of all partitions equally.
8
CHAPTER2: Performance Monitoring
Figure 2.1: The performance characteristics of the DB2 database partitions are shown in
the Performance: Partition Overview screen.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
21/193
Partitioned SAP NetWeaver BW databases have unique package cache require-
ments. Since all application servers connect to the Administration Partition (par-
tition 0), all SAP basis function-related SQL statements will only be compiledand performed on partition 0. Therefore, the Administration Partition requires a
bigger package cache than other data partitions. Package cache quality should be
95 to 98 percent on each partition.
Performance: Database Snapshot
The database performance dialog of the DBA Cockpit is the equivalent of run-
ning the ST04 transaction code. This screen, shown in Figure 2.2, contains tabsfor each of the following key database performance indicators (KPIs):
Buffer pool
Cache
Asynchronous I/O
Direct I/O
Real-time statistics
Locks and deadlocks
Logging
Calls
Sorts
XML storage
By default, the database performance monitor displays database statistics since
the last system reset. The system can be manually reset at any time by clicking
theResetbutton at the top of the screen. To the right of the Reset button, you
will find a Since Reset button and a Since DBM Start button. These toggle the
statistics between the values since the last reset, and the values since the start of
the database manager (the DB2 instance).
9
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
22/193
The Buffer Pool
Disk I/O is relatively slow compared to other types of database operations.Therefore, if a database reduces disk I/O and performs most disk I/O operations
in the background (asynchronous), performance generally improves. On the other
hand, if an SQL statement is forced to wait for disk I/O (synchronous), perfor-
mance generally declines. Administrators should strive for high buffer quality,
fast physical I/O, and few synchronous reads. All of this information is available
in the DBA Cockpit buffer pool statistics, shown in Figure 2.2.
High buffer quality is probably one of the most important criteria for perfor-
mance. If an agent can find the pages it needs already in memory, I/O wait is re-duced and response time improves. For peak performance, overall buffer quality
for the entire database should be above 95 percent, with data hit ratios above 95
percent and indexes hit ratios above 98 percent. Hit ratios can be improved by in-
creasing buffer pool size, compressing the database, improving cluster ratios for
SAP NetWeaver BW, or by optimizing buffer pool allocation, which can be done
automatically by the DB2 Self Tuning Memory Manager (STMM).
10
CHAPTER2: Performance Monitoring
Figure 2.2: This tab of the database snapshot dialog displays statistics about the buffer
pool.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
23/193
Buffer pool hit ratios depend on the ratio of logical and physical reads. Each re-
quest for a page of table or index data is referred to as a logical read. In a
well-tuned system, the majority of logical read requests will be satisfied from thebuffer pool, resulting in buffer pool hits. If a page is not in the buffer pool, a
buffer pool miss occurs, and the page must be read from disk, which is called a
physical read. The buffer pool quality is the ratio of the number of page requests
found in the buffer pool to the total number of logical read requests.
Physical reads and writes are unavoidable, because new transactions are always
reading and writing new data to the database. However, a properly configured da-
tabase will perform most disk I/O asynchronously and in parallel, thereby mini-
mizing the I/O wait experienced by the client and maintaining high buffer
quality. Physical reads and writes can either be synchronous or asynchronous, de-
pending on which DB2 agent (process or thread) performs the I/O operation.
Synchronous I/O is performed directly by the database agent working on behalf
of the client connection, and asynchronous I/O is performed by the DB2
prefetchers and page cleaners. The statistic labeled Average Time for the Physi-
cal Reads and Physical Writes on the DBA Cockpit indicates the I/O subsystem
performance. An average physical read time above 10ms and/or an average phys-
ical write time above 5ms indicates an I/O subsystem that is not performing
optimally.
Asynchronous reads are performed in the background by the DB2 prefetchers,
which anticipate the needs of the applications, and load, from disk into buffer
pools, the pages that are likely to be required. In most cases, the prefetchers read
these pages just before they are needed. For example, during a full table select,
the prefetchers will populate the buffer pool with all of the pages containing data
for that table, so that when the agent tries to access that data, it is already avail-
able in memory.
Synchronous reads occur when an agent reads a page of data from disk itself,
rather than signaling the prefetchers to read the page asynchronously. This occurs
most frequently during random requests for single pages, which are common in
OLTP applications operating on single rows of data via an index. However, this
may also occur if the prefetchers are all busy with other prefetch requests.
11
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
24/193
Each synchronous read request results in I/O wait at the client, because the agent
processing the SQL statement must directly perform a read from disk before it
can continue query processing. For single-row access, it is just as efficient for theagent to read the single page itself. However, for prefetch requests involving
multiple pages, it is far more efficient to have the prefetchers read these pages in
the background.
A properly configured system performs most read operations asynchronously and
minimizes overall system I/O wait. If a large percentage of read operations are
synchronous, it might indicate that the prefetchers are not doing their job effec-
tively. This might be due to slow disks or an inefficient database layout, or the
system might just require more prefetchers to satisfy the database workload.
The physical writes specify the number of pages written from buffer pool to disk.
Similar to a read, a write can be either synchronous or asynchronous, depending
on the agent that performs it. Asynchronous writes are performed in the back-
ground by the DB2 page cleaners at specific checkpoints. These are far more effi-
cient than synchronous writes, which are performed directly by the DB2 agents
to make room in the buffer pool for new data pages being accessed by that agent.
DB2 can perform page cleaning in two different ways: Standard Page Cleaningor Pro-Active Page Cleaning. By default, all new SAP installations use Standard
Page Cleaning.
Standard Page Cleaning
Using Standard Page Cleaning, page cleaners will asynchronously write data to
disk whenever one of the following occurs:
CHNGPGS_THRESH is exceeded.The database configuration parameterCHNGPGS_THRESH specifies the maximum percentage of changed pages
allowed within a DB2 buffer pool. Once a buffer pool reaches this
percentage of changed pages, the DB2 page cleaners are signaled to write
those changed pages to disk in the table space containers. This parameter
is set to 40 percent by SAPinst. To find it in the cockpit, click
Configuration Database Optimization.
12
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
25/193
SOFTMAX is exceeded.The database configuration parameterSOFTMAX
specifies the maximum total size of changed pages in the buffer pool that
have not yet been written to disk. You can find this parameter in the
cockpit by clickingConfiguration Database Logging. It is
specified as a percentage of one log file in size, and is set to 300 by
SAPinst. This means that the buffer pool can contain a maximum of three
log files worth of changes (300 percent of one log file). Once this
parameter is exceeded, the database enters a log sequence number (LSN)
gap situation, and the page cleaners are signaled to begin writing those
changed pages from buffer pool to disk in the table space containers.
Whenever the above two thresholds are exceeded, the DB2 page cleaners begin
writing changed pages from the buffer pool(s) to disk. This avoids LSN gap situa-
tions, and ensures that there is room in the buffer pool for future prefetch requests.
Proactive Page Cleaning
DB2 also has another method of page cleaning, Proactive Page Cleaning, which
is not currently used by default by SAP. Performance testing has indicated that
Standard Page Cleaning currently performs marginally better for most SAP
workloads. However, for OLTP systems with very update-intensive workloads,
performance might improve slightly by enabling Proactive Page Cleaning in the
DB2 profile registry:
db2set DB2_USE_ALTERNATE_PAGE_CLEANING=ON
Using Proactive Page Cleaning, the page cleaners no longer respond to the
CHNGPGS_THRESHparameter. Rather than keeping a percentage of the buffer
pool clean, this alternate method only uses SOFTMAX, and DB2 keeps track ofgood victim pages and their locations in the buffer pool. Good victim pages in-
clude those that have been recently written to disk and are unlikely to be read
again soon. If either a LSN gap occurs, or the number of good victim pages drops
below an acceptable threshold, the page cleaners are triggered. They proceed to
search the buffer pool, write out pages, and keep track of these new good victim
pages. The page cleaners will not only write out pages in a LSN gap situation,
13
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
26/193
but will also write pages that are likely to enter a LSN gap situation soon, based
on the current level of activity.
When the database agents need to read new data into the buffer pool, the
prefetchers read the list of good victim pages, rather than searching through the
buffer pool for victims. This tends to spread writes more evenly, by writing
smaller amounts more frequently. By spreading the page cleaner write operations
over a greater period of time, and avoiding buffer pool searches for victim pages,
high-update workloads might see performance improvements.
Since most SAP workloads on DB2 9.5 have been found to perform marginally
better using Standard Page Cleaning, we recommend using it for all SAP applica-tions. Future changes to Proactive Page Cleaning might increase its usage within
SAP. For now, though, if you have a uniquely heavy-update workload that you
think might benefit from Proactive Page Cleaning, test the change thoroughly to
determine the effect on performance before enabling it in the production system.
The No Victim Buffers element in the DBA Cockpit can help evaluate whether
you have enough page cleaners when using Proactive Page Cleaning. This ele-
ment displays the number of times a database agent was unable to find
pre-selected victim pages in the buffer pool during a prefetch request, and in-stead, needed to search through the buffer pool for suitable victim pages. If this
element is high relative to the number of logical reads, the database page cleaners
are not keeping up with the changes occurring in the database, and more page
cleaners are likely required.
If Proactive Page Cleaning is off, and you are using Standard Page Cleaning, the
No Victim Buffers monitor element can be safely ignored. In the default configu-
ration, Standard Page Cleaning is triggered by CHNGPGS_THRESH andSOFTMAX,
and the prefetchers will usually search the buffer pool to find suitable victimpages. Therefore, you can expect this monitor element to be large.
Synchronous Writes
If the database must read data from disk into a buffer pool, and there are no free
pages remaining in the buffer pool, DB2 must make room, by replacing existing
14
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
27/193
data pages (victims) with the data pages being read. If these victim buffer pool
pages contain changed data, these pages must be written to disk before they are
swapped out of memory. In this case, the pages are written to disk synchronouslyby the DB2 agent processing the SQL statement.
Synchronous writes always result in I/O wait at the client, because the write
operation must occur synchronously, before the buffer pool page can be
victimized (replaced with a new page from disk). A large percentage of
synchronous write operations indicates that the DB2 page cleaners are not
operating effectively. This might be due to slow disks or unbalanced I/O in the
storage system, or the system might require more page cleaners to handle thesystem workload.
Temporary Table Space I/O
The DBA Cockpit also contains I/O characteristics for the temporary table
spaces, displaying the temporary logical and physical reads for both data and in-
dexes. The logical reads display the total number of read requests for temporary
table space data. The physical reads display the number of read requests that
were not satisfied from the buffer pool, and therefore, had to be read physically
from disk.
For most transactional systems, temporary table space I/O should be fairly low,
since most calculations should be performed in memory. SAP NetWeaver BW
systems might show larger temporary table space I/O, but large values here might
still indicate inefficient queries or a need to create higher-level aggregates to
improve query performance.
The Catalog Cache and Package Cache
The second tab in the DBA Cockpit database performance monitor is the Cache
tab, shown in Figure 2.3. This tab displays the details for the database catalog
cache and the package cache.
15
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
28/193
The Catalog Cache
The catalog cache is a portion of database memory that is dedicated to caching
access to table descriptor and authorization information from the database system
catalog tables. These table descriptors include the table information used by DB2
during query optimization. When this data is accessed, it is first read from disk
into the catalog cache, and then the database agents requesting this data read it
from memory. Therefore, high hit ratios on this buffer are important for perfor-
mance. If the most frequently accessed system catalog details can be cached in
memory, unnecessary disk reads can be avoided.
A high catalog cache hit ratio is even more important in multi-partition SAP
NetWeaver BW systems. In a partitioned SAP NetWeaver BW system, the
system catalog tables all reside on the Administration Partition (partition 0).
Therefore, if other partitions need to read system catalog information from disk,
they must request this information from partition 0, which inserts into the catalog
cache on partition 0, and then sends the information to the catalog cache on the
other partition. Caching most of the system catalog information at each partition
avoids both disk I/O and network I/O, and reduces the workload on the
Administration Partition. All of these contribute to better performance.
The default catalog cache size in new SAP installations is 2,560 4KB pages.
Well-configured systems should have a hit ratio of 98 percent and experience no
overflows. If overflows occur, DB2 must allocate more memory from database
shared memory into the catalog cache. Then, when some table descriptor and au-
thorization information is no longer needed for active transactions, it is removed
16
CHAPTER2: Performance Monitoring
Figure 2.3: The Cache tab displays the Catalog Cache and Package Cache statistics.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
29/193
from memory, and the cache is reduced to its configured size. This involves extra
overhead in the system, and should be avoided by increasing the catalog cache size.
The total number of overflows and the high-water mark can be used together
with the cache quality to determine whether or not the default size is adequate for
your workload. The catalog cache size is set by the CATALOGCACHE_SZ database
configuration parameter. To view or change this parameter in the DBA Cockpit,
clickConfiguration Database Database Memory.
The Package Cache
The package cache is another important area of database memory. It is dedicated tocaching compiled static and dynamic SQL statements and optimizer access plans.
When a new dynamic SQL statement is executed, the DB2 optimizer compiles it,
computes an access plan for reading the data pages required to satisfy the query,
and then caches this information in the package cache. The database agents execut-
ing SQL statements then read this access plan from memory. If the same query is
executed multiple times, the access plan can be read from memory, which avoids
repeating the compilation and optimization phase of query processing.
Static SQL statements are embedded in application programs. These statements mustbe precompiled and bound into a package, which gets stored in the DB2 system cata-
log tables. SAP does not use static SQL, so this will not be discussed further.
By default, the package cache size in new SAP installations is dynamically con-
figured and adjusted by DB2, as part of its Self Tuning Memory Manager
(STMM) feature. This allows DB2 to adjust the size of this cache to optimize
overall performance, based on your changing workload. Package cache hit ratio
should remain above 98 percent, and overflows should not occur. The package
cache size is set by the PCKCACHESZ database configuration parameter. To viewor change the package cache size in the DBA Cockpit, clickConfiguration
Database Self-Tuning Memory Manager.
Larger catalog and package cache sizes might be required if the workload in-
volves a large number of SQL statements accessing many different database ob-
jects. However, in most cases, it is recommended that you keep the package
17
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
30/193
cache size set to AUTOMATIC, and let DB2 STMM configure the size based on
your current available memory and optimal overall system performance.
Asynchronous I/O
The third tab in the Database Performance Monitor is Asynchronous I/O, shown
in Figure 2.4. This displays information on the I/O reads and writes that use
background read and write operations to perform disk I/O to and from the DB2
buffer pools, using the DB2 prefetchers and page cleaners. Asynchronous I/O op-
erations anticipate application I/O requirements, and operate in the background to
minimize I/O wait. Therefore, well-performing systems should perform the ma-jority of disk I/O asynchronously.
Asynchronous I/O is performed by the DB2 prefetchers and page cleaners. The
number of prefetchers and page cleaners should be configured to drive the physi-
cal disks in underlying storage system to full capacity. This is set by two data-
base configuration parameters:NUM_IOSERVERS for prefetchers and
NUM_IOCLEANERS for page cleaners. Both are found in the cockpit under
Configuration Database I/O.
New SAP installations default both of these parameters to automatic. This allows
DB2 to calculate the optimal number of prefetchers and page cleaners, when the
database is activated, based on the following formulae:
NUM_IOSERVERS = MAX( MAX over all table spaces
( parallelism setting MAX # of containers in a stripe set
), 3 )
NUM_IOCLEANERS = MAX( CEIL( # CPUs / # local logical partitions )
1, 1 )
The parallelism setting for prefetchers refers to the DB2_PARALLEL_IO registry
variable, which tells DB2 the number of physical disks assembled into the con-
tainers in each table space. This ensures that the number of prefetchers is always
greater or equal to the number of disks available to any one table space, which
enables asynchronous prefetch requests to drive every available disk in parallel.
18
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
31/193
The formula for page cleaners ensures that they are evenly distributed across all
partitions in a partitioned SAP NetWeaver BW system, and that there are never
more page cleaners than CPUs. This prevents asynchronous page cleaning fromaffecting normal transaction processing performance. Ideally, both asynchronous
read and write times should be less than 5 ms.
Direct I/O
Direct I/O is involved whenever a DB2 agent reads from disk or writes to disk,
without using the DB2 buffer pools. Direct I/O is performed in units, the smallest
being a 512-byte disk sector. Direct reads always occur when the database reads
LONG or LOB data, and when a database backup is performed. Direct writes al-
ways occur when LONG or LOB data is written to disk, and when database re-store and load operations are performed.
The Direct I/O tab of the DBA Cockpit screen is shown in Figure 2.5. Direct I/O
should be extremely fast, because it operates on entire disk sectors. Therefore,
read and write times should generally be under 2ms. The average I/O per request
should be proportional to the average size of the LOB columns in the database.
19
CHAPTER2: Performance Monitoring
Figure 2.4: The Asynchronous I/O tab shows statistics for background disk I/O performedby the DB2 prefetchers and page cleaners.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
32/193
Real-Time Statistics (RTS)
The concept of Real-Time Statistics (RTS) was first introduced in DB2 9.5. SAP
Enhancement Package 1 for SAP NetWeaver 7.0 now contains a performance
monitoring screen for this new DB2 feature. RTS allows DB2 to trigger either
statistics collection or estimation during query compilation, if table statistics are
either absent or stale. If statistics collection would exceed 5 seconds, it is done in
the background. Otherwise, it may even be done synchronously during query
compilation, depending on the cost of the query relative to the cost of the statis-tics collection. This feature ensures that recent statistics are always available for
queries, and that performance is never excessively bad due to stale statistics.
The information available in the DBA Cockpit, shown in Figure 2.6, is valuable
for determining the performance impact of RTS. It might suggest the need for
more structured statistics collection for some tables in the system.
20
CHAPTER2: Performance Monitoring
Figure 2.5: The Direct I/O tab displays statistics for database disk I/O that is
not buffered in memory by the DB2 buffer pools.
Figure 2.6: The Real-Time Statistics tab shows details related to RTS statistics
collection.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
33/193
The statistics cache is a portion of the catalog cache used to store real-time statis-
tics information. If RTS is being frequently triggered, a larger catalog cache
might be required.
Asynchronously collected statistics occur when synchronous statistics collection
during query compilation would take longer than 5 seconds. Rather than consum-
ing this time synchronously during query compilation, statistics collection is in-
stead started as a background job, so that subsequent queries will benefit from
newer statistics.
Synchronous statistics collection occurs when a RUNSTATS is triggered to collect
statistics during query compilation. This RUNSTATS may or may not be sampled,
depending on the RUNSTATSprofile for the table and the time estimate for statis-
tics collection. The end user might experience a maximum of 5 seconds extra
time running this query, due to the synchronous RUNSTATS. The number of syn-
chronous RUNSTATS occurrences and the total time consumed by those occur-
rences are displayed in the cockpit.
The final piece of data for RTS is based on statistics fabrication (or statistics esti-
mation). If a sampledRUNSTATS table or index scan consumes too much time,
then new metadata stored in the data and index manager system catalog tables is
used to estimate the current table statistics. Those statistics are immediately made
available in memory for all other queries to use until a RUNSTATS is performed
on the table. In the cockpit, statistics estimation is displayed by the number of
statistics collections during query compilation, and the time spent during query
compilation.
Locks and Deadlocks
Whenever table records are accessed, DB2 places locks on those records to main-
tain transaction integrity and ensure that two transactions cannot update the same
data at the same time. The type of lock used by DB2 depends on the isolation
level defined for the application accessing those records. Traditional DB2 lock-
ing involves the following isolation levels, ordered by increasingly restrictive
locking:
21
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
34/193
UR (Uncommitted Read)Read operations do not acquire any locks.
Uncommitted updates of other transactions can be read immediately.
CS (Cursor Stability)Read-only locks are placed on the current record being
accessed by a cursor. If that record contains an uncommitted update, the read
of that row must wait until that update is committed. This ensures that the
application cannot read uncommitted data, and that the current position of the
cursor cannot be changed while the application is accessing it.
RS (Read Stability)Read-only locks are placed on the entire result setretrieved within a unit of work, and those locks are held until the unit of
work is committed or rolled back. This ensures that any row read during a
unit of work (UOW) remains unchanged until the UOW commits, and that
the application cannot read uncommitted changes from other transactions.
RR (Repeatable Read)Read-only locks are placed on all records
referenced during the processing of the current UOW. This includes all
rows in the result set, plus any rows evaluated and excluded due to WHERE
clause restrictions in the query. This ensures that new rows do not appear
in the result set, existing rows remain unchanged, and uncommitted
updates from other transactions cannot be read.
The default isolation level for most SAP applications is Uncommitted Read,
which allows the highest level of concurrency within the database. SAP transac-
tion integrity is managed within the SAP application. One SAP transaction may
involve multiple database transactions, each of which is committed into the SAP
update tables. While one SAP transaction updates data in the update tables, otherSAP transactions are reading committed data from the tables containing the per-
manent, committed data. Therefore, concurrent SAP transactions always read
committed data. When an SAP transaction is finally committed, those update ta-
ble records are applied to the target database tables by the SAP update work pro-
cesses, and other transactions then see the committed changes from the entire
SAP transaction.
22
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
35/193
One potential exception to the UR default isolation level occurs when accessing
cluster or pool tables. Since reading a single logical row may involve reading
multiple physical rows, more restrictive locking might be required. SAP first triesto read the logical row with UR. If this does not produce a consistent read of all
physical rows, SAP will read again, first trying CS, and if necessary, finally
reading with RS, which will guarantee read consistency for all physical rows in
the logical record. However, inconsistent reads on logical rows using UR rarely
occur, and most cluster/pool table reads succeed the first time with UR.
Database locks are stored in a portion of database memory called the lock list.
When row locks are acquired, they are added to this lock list. If the size of the
row locks exceeds the size of the lock list, DB2 will convert multiple row locks
on a single table into a single table lock. This lock escalation frees up space in
the lock list for other row locks. However, it can also reduce concurrent access to
the table involved in the escalation. At best, this might reduce performance for
applications accessing that table; at worst, it might result in increased lock waits
or deadlock scenarios in other concurrently running applications.
Normal lock escalations allow read access to the locked tables, but force writes to
wait for the application holding the lock to commit. Exclusive lock escalations
also disallow reads, thereby reducing concurrency even further. Therefore,
administrators should try to completely avoid lock escalations, by ensuring that
the lock list is large enough to contain the locks for the concurrent activity in the
SAP system.
The size of the lock list is set by the LOCKLIST database configuration parameter,
which can be found in the cockpit underConfiguration Database
Self-Tuning Memory Manager. Lock list utilization can be calculated using the
lock_list_in_use monitor element and the lock list size. If utilization is high, con-sider increasing the lock list size. These details can be easily found within the
Locks and Deadlocks section of the SAP DBA Cockpit for DB2, which is shown
in Figure 2.7.
By default, SAPinst enables DB2 STMM. Therefore, LOCKLIST is set to
AUTOMATIC, allowing DB2 to dynamically adjust the size of the lock list to avoid
23
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
36/193
lock escalations and optimize overall system performance. Normally, lock esca-
lation is extremely rare for databases with a properly configured lock list or for
databases using STMM.
Another parameter automatically tuned by STMM is MAXLOCKS. This specifies
the maximum percentage of the lock list that can be consumed by a single appli-
cation before lock escalation will occur for locks held by that application. Using
STMM, DB2 can automatically adjust this percentage, depending on the number
of concurrent transactions and the number of locks held by each concurrent unit
of work.
If there is only one active transaction, DB2 will adjust this to a large percentage.
However, if many applications are holding locks, this percentage might need to
be lower to avoid a scenario where one application consumes most of the lock
list, while the others quickly run out of space in the lock list and are forced to es-
calate. Properly configuring the LOCKLIST andMAXLOCKSparameters or using
STMM will prevent lock escalations.
24
CHAPTER2: Performance Monitoring
Figure 2.7: The Locks and Deadlocks tab displays information on lock management and
deadlock occurrences.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
37/193
If lock escalations are occurring, then abnormally large values can be expected for
the lock wait monitor elements, too. If lock escalations occur, other applications ac-
cessing that same table must wait for the escalating application to commit. In addi-tion, if more applications are waiting for table locks to be released, there is a
greater possibility that one of these waiting applications will already be holding a
lock that will be requested by the escalating application. This would result in a
deadlock, with each application waiting for locks already held by the other.
Large lock wait values without lock escalations or deadlocks might indicate that
custom applications are not efficiently committing their units of work. Custom
applications should try to hold locks for as little time as possible, by performing
efficient SQL statements and accessing only required records, and by performingrelated updates together, followed immediately by committing the unit of work.
Infrequent commits can hold locks excessively long, and increase lock wait
scenarios.
A lock timeout occurs when an application waits to acquire a lock for longer than
the LOCKTIMEOUT database configuration parameter, which is set to 3,600 sec-
onds (1 hour). This default value is much larger than any application should be
required to wait for locks. If a lock wait occurs, an application has probably hung
in the middle of a unit of work, and is holding locks abnormally. In this scenario,an administrator will likely need to identify the hung database agent, and manu-
ally terminate that application using a command:
db2 force application (appl_handle)
This will cause a rollback and release the locks currently held by that application.
Logging
The transactional log files of the database maintain database integrity by contain-
ing a physical copy, on disk, of all committed database transactions. When data is
updated, the changes are made directly in the DB2 buffer pool, and logged in the
DB2 log buffer. When a transaction commits, each entry in the log buffer must
be successfully written from the log buffer to the log files before the commit
25
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
38/193
returns successfully to the client. Since writes to the log files occur synchro-
nously with each commit, fast SAP dialog response times depend on fast writes
to the DB2 transactional log files.
DB2 contains two kinds of log files: primary and secondary. The number and
size of these log files are set with the LOGPRIMARY, LOGSECOND, andLOGFILSZ
database configuration parameters. Primary log files are pre-allocated when the
database is created. Secondary log files are allocated on demand, whenever ac-
tive transactions exceed the total size of the primary log files. Therefore, the total
size allocated to primary log files should be large enough to hold all the log re-
cords expected from concurrent transactions during normal database activity.Secondary log files should only be required for infrequent spikes in activity,
which may require additional log space.
Logging can be configured for eithercircularorarchive logging. Circular log-
ging reuses primary log files once they no longer contain log records required for
crash recovery, which means that point-in-time recovery is not possible with cir-
cular logging. Therefore, circular logging is not suitable for production systems.
Production systems require archive logging, which ensures that all log files pro-
duced during the entire lifetime of the database are saved, and that point-in-time
recovery is always possible. When a primary log file becomes full, it is archived
(copied) by DB2 to the locations set in the LOGARCHMETH1 andLOGARCHMETH2
database configuration parameters. Once the log file is no longer needed for
crash recovery, it is renamed to the next log file sequence number, and its header
is re-initialized for re-use. During normal workloads in properly configured sys-
tems, the next empty primary log file usually already exists when the current log
file becomes full, and a transaction spanning multiple log files rarely incurs the
overhead of allocating the next log file.
The Logging tab, shown in Figure 2.8, displays the number and size of log files
available and allocated in the system. If the database is using secondary logs, you
can see the number currently allocated, and the maximum secondary log file
space used by the database.
26
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
39/193
This information can help determine if the primary log space is adequate for your
current workload. In general, we recommend that the log file system should be
1.5 times the size of all primary and secondary log files configured for your sys-
tem. This ensures enough space for all configured log files, plus extra space for
inactive (online archive) logs waiting to be archived, or new logs being formatted
for future use.
If secondary log space is being used consistently, logging overhead may be re-
duced by allocating more primary log space. This is done by either increasing the
number of primary log files or increasing the log file size. First, always ensure
that the log file system is large enough to contain all of the configured logs. The
cockpit also displays the database application ID with the oldest uncommittedtransaction. This can help identify long-running transactions that might need
attention.
The Log Buffer Consumption section is valuable for determining the effective-
ness of page cleaning. The LSN Gap value specifies the percentage of the
SOFTMAX checkpoint that is currently consumed in log files by dirty pages. This
27
CHAPTER2: Performance Monitoring
Figure 2.8 The Logging tab displays information on log file consumption and logging I/O.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
40/193
includes pages that have been changed in a buffer pool by both committed and
uncommitted transactions, but which have not yet been written to disk in the ta-
ble spaces. If this is above 100 percent, the page cleaners are unable to keep upwith the transaction workload on the system, and more page cleaners might be re-
quired. The Restart Range value is similar, but corresponds to the percentage of
SOFTMAX occupied in the log files by committed transactions. Statements in this
Restart Range will need to be rolled forward during crash recovery. Again, if this
is greater than SOFTMAX, more page cleaners might be required.
The I/O characteristics of the log file system are also provided. The Log Pages
Read displays the physical log file page reads required during rollback operations
in the database, and the Log Pages Written displays the pages of transactional
data written into the log files. The transaction commit time depends on the log
file systems write performance. Therefore, having the fastest log file system
possible minimizes dialog response time. A well-performing system should have
log file system write times below 2 ms.
Ideally, very few log buffer overflows should occur. This indicates the number of
times any database agent has waited for log buffer flushes in order to write into
the log buffer. These can occur when large transactions produce a series of log
records larger than the buffer, or when high transaction volumes consume the en-
tire buffer with many smaller log records simultaneously. When this occurs, all
in-flight transactions must wait for the log buffer to be written to disk before they
can continue writing log records into the buffer. This introduces I/O wait into all
in-flight transactions and hurts performance. For optimal performance, the log
buffer should be large enough to avoid overflows during normal workloads.
Calls
The Calls tab, shown in Figure 2.9, contains a summary of the different types of
SQL statements issued, and their performance impact on the SAP system. This
displays the number of rows read, deleted, inserted, selected, and updated. These
can be compared to the number of DML and DDL statements executed and their
execution time, to understand the average number of rows read per SQL state-
ment, and the time spent processing those statements within the database.
28
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
41/193
The Hash Joins section shows some interesting statistics on the hash join opera-
tions performed by the database. DB2 performs hash joins when large amounts of
data are joined by equality predicates on columns of the same data type (for ex-
ample,tab1.colA = tab2.colB). First, the inner table is scanned, and the relevant
rows are copied into memory and partitioned by a hash function. The hash func-
tion is then applied to the rows from the outer table, and the join predicates arethen only compared for inner and outer table rows hashing to the same partition.
If the hash join data exceeds sort heap memory, DB2 will consume temporary ta-
ble space on disk to compute the join. Obviously, performance will be better if
this can be avoided, and instead, the join can be done entirely within a sort heap.
If the total hash join data exceeds the sort heap by less than 10 percent, this
counts as a small overflow. If the number of small overflows is greater than 10
percent of the total overflows, avoiding these small overflows with a larger sort
heap may improve performance. If a single partition of data from the hashingfunction (the set of rows hashing to the same value) is larger than the sort heap, a
hash loop results. When this occurs, the intermediate join of that one section of
data overflows to temporary table space, causing extra disk I/O for the join of in-
dividual hash partitions.
29
CHAPTER2: Performance Monitoring
Figure 2.9: The Calls tab displays how different types of SQL statements contribute to the
load on the database.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
42/193
For performance reasons, always try to minimize the number of hash loops and
hash join overflows. With DB2 9.5, the sort heap memory parameters default to
automatic settings using the DB2 Self-Tuning Memory Manager. This allowsDB2 to automatically adjust the available sort heap memory to avoid unnecessary
hash join overflows or hash loops.
Sorts
The Sorts tab, shown in Figure 2.10, displays memory usage and overflows from
database sorts. The Sort Overflows value is probably the most important one on
this tab. Transactional systems should have less than one percent of total sorts over-
flowing from sort memory to temporary table space. BW systems may have more,but overall, sort memory should be configured to avoid most sort overflows.
The private and shared sort heap parameters can be compared with the current al-
located memory and high-water mark, to determine whether the sort memory
heaps are properly configured. DB2 9.5 defaults to automatic shared sort memory
and the Self-Tuning Memory Manager. This allows DB2 to manage sort memory
allocation based on overall system requirements, which avoids unnecessary sort
memory allocation and prevents most sort overflows.
30
CHAPTER2: Performance Monitoring
Figure 2.10: The Sorts tab shows the memory consumed by database sort operations.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
43/193
XML Storage
The XML Storage tab provides I/O characteristics for XML Storage Objects(XDA). This is only valid for database tables using the XML data type to lever-
age the DB2 PureXML features for storing and accessing XML documents na-
tively in XML format.
As of the writing of this book, SAP currently does not use DB2 PureXML fea-
tures. Therefore, this tab is really only valid for non-SAP databases cataloged
into the cockpit, or for user tables created manually by SAP customers.
Performance: Schemas
There should be very few schemas existing within a SAP database. The vast ma-
jority of database access is done through the SAP connection users, which default
to SAP for ABAP systems, andSAPDB for Java systems. The
only other users who generally connect are the SAP admin user, ADM,
and the DB2 instance owner, DB2.
The Schemas dialog screen can be used to identify the activity of users
connecting to any database partition from outside the SAP application. I/Operformance characteristics of reads and writes can be monitored for each
schema.
Performance: Buffer Pool Snapshot
The default installation of SAP on DB2 creates all table spaces using 16KB
pages. By default, the only visible buffer pool is IBMDEFAULTBP, which is also
created with 16KB pages. If other table space sizes are created, then other buffer
pools corresponding to each unique page size must be created, too. However,SAP recommends keeping everything in your system at a uniform page size of
16KB. This simplifies configuration and avoids the additional complexity in-
volved when joining tables with different page sizes.
The buffer pool snapshot provides the logical and physical read statistics for the
data, index, and temporary table spaces on all database partitions. If different
31
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
44/193
buffer pools have been created for different database objects, this provides an
easy interface to compare the individual statistics for each buffer pool on each
database partition.
The initial screen contains a list of all visible buffer pools created in the system,
along with an overview of their hit ratios and read characteristics.
Double-clicking on any buffer pool partition returns a more detailed buffer pool
snapshot for that particular buffer pool on that particular partition, as shown in
Figure 2.11. This displays the data and index read statistics, buffer quality, and
utilization state of the buffer pool. It also includes tabs showing the detailed
asynchronous and direct I/O operations, and performance characteristics for this
buffer pool. All of these details are important for proper performance tuning ofeach individual buffer pool.
32
CHAPTER2: Performance Monitoring
Figure 2.11: The Buffer Pool Snapshot displays detailed I/O information for an individual
buffer pool.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
45/193
As a safety net, DB2 is also pre-configured with hidden buffer pools for each
possible page size (4K, 8K, 16K, and 32K). These hidden buffer pools ensure
that an appropriate buffer pool is always available. These hidden buffer poolsmay be used if the system does not contain enough memory to allocate the de-
fined buffer pools, errors allocating the buffer pools occur during the database
activation, or if anything in the database performs I/O using a page size without a
corresponding user-defined buffer pool. Since these hidden buffer pools are only
16 pages in size, performance will likely suffer if they are used. An entry is
logged in the notification log whenever a hidden buffer pool is used.
Performance: Tablespace Snapshot
Evenly distributed I/O and fast access to the most frequently accessed data are
critical for performance. The performance statistics for each individual table
space can help administrators identify data hot spots or inadequate buffer pool
configurations. The Performance: Tablespace Snapshot screen, shown in Figure
2.12, displays the I/O statistics of each table space on each partition.
First, the most frequently accessed table spaces should have the highest bufferpool hit ratios. Table spaces with a high number of logical reads should have a
buffer pool quality of at least 95 to 98 percent. The frequently accessed index ta-
ble spaces (with names ending inI) are especially critical for high hit ratios.
Next, the physical read and write times for all table spaces should be fairly fast.
Ideally, both read and write times should be under 5ms. If all table spaces have
slower I/O, you might simply have slow disks. However, this might also be a
sign of disk contention, especially if more frequently accessed table spaces areslower than others. To improve performance, spread the data across a greater
number of physical disks, or move one or more frequently accessed tables to a
new table space on a new series of disks. The Tablespace Snapshot can be used,
together with theOperating System Monitor Detailed analysis menu
Disk Snapshot (from transaction ST06), to lay out table spaces and balance data-
base I/O evenly across all SAPDATA file systems.
33
CHAPTER2: Performance Monitoring
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
46/193
Similar to the previous buffer pool snapshot, double-clicking any row displays a
more detailed table space snapshot for the chosen table space and partition. Thissnapshot shows the detailed buffer pool statistics, and the asynchronous and di-
rect I/O operations and performance characteristics.
Performance: Table Snapshot
Page reorganizations and overflow record accesses are two key performance indi-
cators for individual tables. Page reorganizations occur when an insert or update
is done to a data page that contains enough free space for the new data, but the
free space is fragmented within that page. Before the insert or update is per-formed, the single page of data is reorganized to consolidate the free space at the
end of the page, and then the insert or update proceeds. This extra overhead can
hurt insert and update performance. However, if an update is being done, and a
page reorganization cannot reclaim enough contiguous space for the updated
row, the row must be moved to a new page. An overflow record (or pointer) is
then created to point from the original location to the new location on the other
34
CHAPTER2: Performance Monitoring
Figure 2.12: The Tablespace Snapshot displays the I/O characteristics of all table spaces.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
47/193
page. When this row is accessed, DB2 must perform two I/O reads instead of
one: the first to read the pointer from the original location, and the second to read
the data from the pointer.
If a table contains a large number of page reorganizations or overflow accesses,
both of these problems can be fixed by reorganizing the table. Double-clicking
any table from the screen in Figure 2.13 loads the Single Table Analysis screen
(explained fully in the Chapter 3). The table reorganization can be executed from
Single Table Analysis, or scheduled through the DBA Planning Calendar
(discussed in Chapter 4).
Also, if table space analysis has indicated unbalanced I/O, the table snapshot can
be used to identify the most frequently accessed tables. If several heavily ac-
cessed tables reside in the same table space, I/O can be balanced by separating
these tables into different table spaces on different sets of physical disks.
35
CHAPTER2: Performance Monitoring
Figure 2.13: The Table Snapshot dialog displays data access characteristics of individual
tables.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
48/193
Performance: Application Snapshot
The main dialog of the Performance: Application Snapshot screen displays asummary list of all the database applications with active connections to the data-
base. This overview gives descriptions of the applications, their status, their
buffer quality, and the number of reads performed. Almost all of these will corre-
spond to SAP work processes.
Double-clicking any application in the initial list displays a detailed snapshot for
that single application. Shown in Figure 2.14, this snapshot displays all of the key
application statistics, organized conveniently into unique screen tabs.
The first Application tab describes the application on the host, and displays the
client user and SAP application server executing this application. The Agents tab
36
CHAPTER2: Performance Monitoring
Figure 2.14: The Application Snapshot contains many tabs for accessing detailed informa-
tion on the resource consumption of the database applications.
5/25/2018 SAP DBA COCKPIT - Flight Plans for DB2 LUW Database Administrators
49/193
describes the number of agents, processing time, and memory usage for this ap-
plication. Note that with DB2 9.5, the parameters for the number of agents in the
database default to automatic, and are dynamically maintained by DB2 to opti-mize memory utilization and performance.
The Buffer Pool tab displays the applications detailed data, index and temporary
table space read statistics, and buffer pool quality. The read statistics can indicate
the I/O efficiency of the queries in this application. The performance details of
the non-buffered I/O (e.g. LOB access, backup and restore) are shown in the
Direct I/O tab.
The Locks and Deadlocks, Calls, Sorts, and Cache tabs contain the same infor-
mation as the database performance tabs, except that the details are specific to the
currently selected application. If an application is holding too many locks, caus-
ing lock escalations, or involved in deadlocks, consider looking more closely at
the application coding and SQL. A properly coded application will hold as few
locks as possible and commit as frequently as possible, so that locks are released
quickly. An application should commit as frequently as possible, and not perform
unnecessary calculations inside SQL units of work. The SQL statements should
also try to reduce the amount of data accessed during a query, and only return the
rows of relevance for the application.
The Unit of Work tab displays the length of time and log space consumption of
the current transaction. The Statement tab shows the statistics of the current state-
ment within the current unit of work. The Statement Text tab displays the current
SQL statement being executed. This screen also contains buttons to load the
optimizer execution plan for the statement, or to view the ABAP source code for
the program executing this SQL statement. These tools can be used to analyze the
program logic and SQL execution plans, to ensure efficient SQL and indexed ac-
cess to the data pages being fetched.
Performance: SQL Cache Snapshot
If administr
Recommended