cockpit flightplansfordb2luwdatabaseadministrators

8/8/2019 COCKPIT FlightPlansforDB2LUWDatabaseAdministrators

1/193


2/193

SAP DBA CockpitFlight Plans for

DB2 LUW Database Administrators

Eduardo Akisue

Jeremy Broughton

Liwen Yeow

Patrick Zeng

Foreword by Torsten Ziegler


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


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 [email protected].

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 worldteaching 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 [email protected].


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 [email protected]

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

[email protected] .

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

[email protected]


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


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


8/193

Performance: Active Inplace Table Reorganizations . . . . . . . 41

Performance: HistoryDatabase . . . . . . . . . . . . . . . . . . 41

Performance: HistoryTables . . . . . . . . . . . . . . . . . . . 42Performance 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


9/193

Updating Statistics . . . . . . . . . . . . . . . . . . . . . . . 86

Table Reorganization. . . . . . . . . . . . . . . . . . . . . . 87

Custom Job Scripts . . . . . . . . . . . . . . . . . . . . . . . 87The 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


10/193

Monitoring Settings . . . . . . . . . . . . . . . . . . . . . . . 128

Automatic Maintenance Settings. . . . . . . . . . . . . . . . . 130

Automatic Backups . . . . . . . . . . . . . . . . . . . . . . 130Automatic 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


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


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


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 administratorswith a more comprehensive administration and

monitoring 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


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


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


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.


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



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 of

the 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 the Addbutton 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



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


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

CHAPTER 2: Performance Monitoring


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


Figure 2.1: The performance characteristics of the DB2 database partitions are shown in

the Performance: Partition Overview screen.


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

the Resetbutton 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



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


Figure 2.2: This tab of the database snapshot dialog displays statistics about the buffer

pool.


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



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



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 clicking Configuration 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



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



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 physicallyfrom 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



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


Figure 2.3: The Cache tab displays the Catalog Cache and Package Cache statistics.


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



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



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


Figure 2.4: The Asynchronous I/O tab shows statistics for background disk I/O performedby the DB2 prefetchers and page cleaners.


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


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.


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



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 appearin 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



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



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


Figure 2.7: The Locks and Deadlocks tab displays information on lock management and

deadlock occurrences.


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



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 eithercircular orarchive 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



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 uncommitted

transaction. 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


Figure 2.8 The Logging tab displays information on log file consumption and logging I/O.


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



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


Figure 2.9: The Calls tab displays how different types of SQL statements contribute to the

load on the database.


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


Figure 2.10: The Sorts tab shows the memory consumed by database sort operations.


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



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


Figure 2.11: The Buffer Pool Snapshot displays detailed I/O information for an individual

buffer pool.


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 the Operating 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



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


Figure 2.12: The Tablespace Snapshot displays the I/O characteristics of all table spaces.


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


Figure 2.13: The Table Snapshot dialog displays data access characteristics of individual

tables.


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


Figure 2.14: The Application Snapshot contains many tabs for accessing detailed informa-

tion on the resource consumption of the database applications.


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 administrators are going to spend their valuable time tuning the performance of

individual queries, then it makes sense to focus on the queries that most affect the

37



50/193

system. The Performance: SQL Cache Snapshot screen, shown in Figure 2.15, al-

lows administrators to easily identify the queries that are consuming the largest

amount of resources.

In the screen, the columns listing numbers of executions, total execution time,

and average execution time allow the DBA to identify the queries that take the

most execution time. The buffer pool hit ratio is given for each query, to identify

how much disk I/O the query is causin

cockpit flightplansfordb2luwdatabaseadministrators

Documents