sap dba cockpit - flight plans for db2 luw database administrators

DB2 is now the database most recommended for use with SAP applications, and DB2 skills are now critical for all SAP technical professionals. The most important tool within SAP for database administration is the SAP DBA Cockpit, which provides a more extensive administrative interface on DB2 than any other database. This book steps through every aspect of the SAP DBA Cockpit for DB2. Readers will quickly learn how to use the SAP DBA Cockpit to perform powerful DB2 administration tasks and performance analysis. This book provides both DB2 beginners and experts an invaluable reference for the abundance of information accessible from within the SAP DBA Cockpit for DB2. It makes it easy for SAP NetWeaver administrators, consultants, and DBAs to understand the strengths of DB2 for SAP, and how to leverage those strengths within their own unique application environments.

EDUARDO AKISUE

Certified DB2 9 Administrator

Certified Informix Administrator

Certified SAP Technology Consultant

SAP Certified OS/DB Migration Consultant

JEREMY BROUGHTON

SAP Certified Basis Consultant for DB2 on NetWeaver 2004


LIWEN YEOW

Certified Technology Associate–System Administration (DB2) for SAP NetWeaver 7.0

SAP Certified Technology Consultant for DB/OS Migration

PATRICK ZENG

Certified DB2 Solutions Expert


MC Press Online, LP125 N. Woodland TrailLewisville, TX 75077

SAP DBA COCKPITFlight Plans for DB2 LUW Database Administrators

SAP DBA CockpitFlight Plans for

DB2 LUW Database Administrators

Eduardo AkisueJeremy Broughton

Liwen YeowPatrick Zeng

Foreword by Torsten Ziegler

SAP DBA Cockpit: Flight Plans for DB2 LUW Database AdministratorsEduardo Akisue, Jeremy Broughton, Liwen Yeow, Patrick ZengForeword 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 authordo 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 orcopyrighted by their respective manufacturers.

This publication is protected by copyright, and permission must be obtained from the publisherprior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or byany means, electronic, mechanical, photocopying, recording, or likewise.

For information regarding permissions or special orders, please contact:MC PressCorporate Offices125 N. Woodland TrailLewisville, TX 75077 USA

For information regarding sales and/or customer service, please contact:MC PressP.O. Box 4300Big Sandy, TX 75755-4300 USA

ISBN: 978-158347-089-3

About the Authors

Eduardo Akisue is a member of the WW DB2 SAP TechnicalSales Enablement and Support team. Previous to his currentrole, he worked for many years supporting DB2 and Informixcustomers in the Latin America region. He is a Certified DB2 9Administrator, a Certified Informix Administrator, and anInformix “dial-up” Engineer. He is also a Certified SAP Tech-nology Consultant and an SAP Certified OS/DB MigrationConsultant. Eduardo can be reached at [email protected].

Jeremy Broughton is a Technical Enablement Specialist forIBM DB2 and SAP. He has worked within the IBM DB2 De-velopment Lab for 10 years, first developing infrastructure andtooling for DB2 development, and then rewriting internal DB2code to optimize compilation performance and developmentagility. For the past three years, Jeremy has been dedicated tohelping SAP professionals leverage the strengths of DB2within SAP implementations. He has assisted with proofs ofconcept, provided consulting to customers implementing SAPon DB2, and presented numerous workshops around the worldteaching DB2 administration and migration methodology forSAP systems. He is an SAP Certified Basis Consultant for DB2on NetWeaver 2004, and an SAP Certified OS/DB MigrationConsultant. Jeremy can be reached at [email protected].

Liwen Yeow is the WW SAP Technical Sales Manager forDB2 Distributed Platforms. He has been with IBM since 1988and has worked in the SAP field since 1995 in multiple capaci-ties: as part of DB2 Service, as an SAP Consultant for DB2, asa Customer Advocate for many of the large SAP-DB2 custom-ers, and as Manager of the IBM-SAP Integration and SupportCenter. In his current role, he is responsible for the enablementof the Technical Pre-Sales teams and provides guidance to theSales teams in SAP sales opportunities. He is a Certified Tech-nology Associate–System Administration (DB2) for SAPNetWeaver 7.0, and an SAP Certified Technology Consultantfor DB/OS Migration. Liwen can be reached [email protected]

Patrick Zeng was a member of the WW DB2 SAP TechnicalSales Enablement and Support team and currently works as aDBA at Bank of America. He has many years’ worth of expe-rience supporting SAP and DB2 customers. He is a CertifiedDB2 Solutions Expert and a Certified SAP Technology Con-sultant. Patrick can be reached [email protected].

Torsten Ziegler has been the Development Manager for SAPNetWeaver on IBM DB2 for Linux, UNIX, and Windows since2001. After having worked in other industries, he joined SAPas a developer in 1997. In his current role, he is responsible fordevelopment, maintenance, and development support for allDB2-specific components of SAP NetWeaver and applicationsbased on NetWeaver. He can be reached [email protected]

Acknowledgments

The authors would like to express their gratitude for the technical contributionsreceived by the following colleagues:

At IBM:Guiyun CaoMartin MezgerKarl Fleckenstein

At SAP AG:Torsten ZieglerRalf StaufferAndreas ZimmermannSteffen SiegmundBritta Bachert

Contents

Foreword by Torsten Ziegler. . . . . . . . . . . . . . . . . . . vi

Chapter 1: The SAP DBA Cockpit . . . . . . . . . . . . . . . . . . . . . . 1Central Monitoring of Remote Systems . . . . . . . . . . . . . . 5Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2: Performance Monitoring . . . . . . . . . . . . . . . . . . . . . 6Performance: Partition Overview . . . . . . . . . . . . . . . . . . 7Performance: Database Snapshot . . . . . . . . . . . . . . . . . . 9

The Buffer Pool . . . . . . . . . . . . . . . . . . . . . . . . 10The Catalog Cache and Package Cache . . . . . . . . . . . . 15Asynchronous I/O . . . . . . . . . . . . . . . . . . . . . . . 18Direct I/O. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Real-Time Statistics (RTS). . . . . . . . . . . . . . . . . . . 20Locks and Deadlocks. . . . . . . . . . . . . . . . . . . . . . 21Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Sorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30XML Storage . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Performance: Schemas. . . . . . . . . . . . . . . . . . . . . . . 31Performance: Buffer Pool Snapshot . . . . . . . . . . . . . . . . 31Performance: Tablespace Snapshot . . . . . . . . . . . . . . . . 33Performance: Table Snapshot . . . . . . . . . . . . . . . . . . . 34Performance: Application Snapshot . . . . . . . . . . . . . . . . 36Performance: SQL Cache Snapshot . . . . . . . . . . . . . . . . 37Performance: Lock Waits and Deadlocks . . . . . . . . . . . . . 39

i

Performance: Active Inplace Table Reorganizations . . . . . . . 41Performance: History–Database . . . . . . . . . . . . . . . . . . 41Performance: History–Tables . . . . . . . . . . . . . . . . . . . 42Performance Warehouse . . . . . . . . . . . . . . . . . . . . . . 43Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Chapter 3: Storage Management . . . . . . . . . . . . . . . . . . . . . . 45Automatic Storage . . . . . . . . . . . . . . . . . . . . . . . . . 47Table Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

The Technical Settings Tab . . . . . . . . . . . . . . . . . . 51The Storage Parameters Tab . . . . . . . . . . . . . . . . . . 53The Containers Tab . . . . . . . . . . . . . . . . . . . . . . 54DMS/SMS Table Spaces . . . . . . . . . . . . . . . . . . . . 54

Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Tables and Indexes. . . . . . . . . . . . . . . . . . . . . . . . . 57Single Table Analysis . . . . . . . . . . . . . . . . . . . . . . . 60

The Table Tab . . . . . . . . . . . . . . . . . . . . . . . . . 61The Indexes Tab . . . . . . . . . . . . . . . . . . . . . . . . 63The Table Structures Tab . . . . . . . . . . . . . . . . . . . 64The RUNSTATS Control Tab . . . . . . . . . . . . . . . . . 65The Index Structures Tab . . . . . . . . . . . . . . . . . . . 67The RUNSTATS Profile Tab . . . . . . . . . . . . . . . . . 67The Table Status Tab. . . . . . . . . . . . . . . . . . . . . . 67The Compression Status Tab. . . . . . . . . . . . . . . . . . 69

Virtual Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Historical Analysis . . . . . . . . . . . . . . . . . . . . . . . . 75

The Database and Table Spaces . . . . . . . . . . . . . . . . 77Tables and Indexes . . . . . . . . . . . . . . . . . . . . . . . 78

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Chapter 4: Job Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 81The Central Calendar . . . . . . . . . . . . . . . . . . . . . . . 81The DBA Planning Calendar . . . . . . . . . . . . . . . . . . . 83

REORGCHK for All Tables . . . . . . . . . . . . . . . . . . 84Scheduling Backups . . . . . . . . . . . . . . . . . . . . . . 85Archiving Log Files to a Tape Device . . . . . . . . . . . . . 86

ii

Updating Statistics . . . . . . . . . . . . . . . . . . . . . . . 86Table Reorganization. . . . . . . . . . . . . . . . . . . . . . 87Custom Job Scripts . . . . . . . . . . . . . . . . . . . . . . . 87

The DBA Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Back-end Configuration . . . . . . . . . . . . . . . . . . . . . . 89SQL Script Maintenance. . . . . . . . . . . . . . . . . . . . . . 90Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Chapter 5: Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . 92The Backup Strategy. . . . . . . . . . . . . . . . . . . . . . . . 93Utility Throttling. . . . . . . . . . . . . . . . . . . . . . . . . . 94Scheduling Backups in the DBA Cockpit . . . . . . . . . . . . . 95

Multi-partition Databases . . . . . . . . . . . . . . . . . . . 99Advanced Backup Technology . . . . . . . . . . . . . . . . 100The DB2 Recovery History File . . . . . . . . . . . . . . . 100

The Backup and Recovery Overview Screen . . . . . . . . . . 102The Database Backup Tab . . . . . . . . . . . . . . . . . . 102The Archived Log Files Tab . . . . . . . . . . . . . . . . . 102

Logging Parameters . . . . . . . . . . . . . . . . . . . . . . . 103The Log Directory . . . . . . . . . . . . . . . . . . . . . . 104The ARCHMETH1 Tab . . . . . . . . . . . . . . . . . . . 105

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Chapter 6: Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 106The Overview Screen. . . . . . . . . . . . . . . . . . . . . . . 108The Database Manager . . . . . . . . . . . . . . . . . . . . . . 109The Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Registry Variables . . . . . . . . . . . . . . . . . . . . . . . . 117

Environment Variables . . . . . . . . . . . . . . . . . . . . 118Registry Variables . . . . . . . . . . . . . . . . . . . . . . 118

Parameter Changes . . . . . . . . . . . . . . . . . . . . . . . . 121Database Partition Groups . . . . . . . . . . . . . . . . . . . . 122Buffer Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Special Tables Regarding RUNSTATS . . . . . . . . . . . . . 125File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Data Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

iii

Monitoring Settings . . . . . . . . . . . . . . . . . . . . . . . 128Automatic Maintenance Settings . . . . . . . . . . . . . . . . . 130

Automatic Backups . . . . . . . . . . . . . . . . . . . . . . 130Automatic RUNSTATS. . . . . . . . . . . . . . . . . . . . 131Automatic REORG . . . . . . . . . . . . . . . . . . . . . . 132

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Chapter 7: The Alert Monitor . . . . . . . . . . . . . . . . . . . . . . . . 135The Alert Monitor. . . . . . . . . . . . . . . . . . . . . . . 136The Alert Message Log . . . . . . . . . . . . . . . . . . . . 137Alert Configuration . . . . . . . . . . . . . . . . . . . . . . 138Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Chapter 8: Database Diagnostics . . . . . . . . . . . . . . . . . . . . . 140The Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . 141The EXPLAIN Option . . . . . . . . . . . . . . . . . . . . . . 142The New Version of EXPLAIN . . . . . . . . . . . . . . . . . 146Missing Tables and Indexes . . . . . . . . . . . . . . . . . . . 147The Deadlock Monitor . . . . . . . . . . . . . . . . . . . . . . 149

Creating the Deadlock Monitor . . . . . . . . . . . . . . . 151Enabling the Deadlock Monitor . . . . . . . . . . . . . . . 151Analyzing the Information Collected . . . . . . . . . . . . . 151Stopping the Deadlock Monitor . . . . . . . . . . . . . . . 154Resetting or Dropping the Deadlock Monitor . . . . . . . . 154

The SQL Command Line. . . . . . . . . . . . . . . . . . . . . 154The Index Advisor . . . . . . . . . . . . . . . . . . . . . . . . 156

Indexes Recommended by DB2 . . . . . . . . . . . . . . . 157Creating Virtual Indexes . . . . . . . . . . . . . . . . . . . 157

The Cumulative SQL Trace . . . . . . . . . . . . . . . . . . . 159The DBSL Trace Directory. . . . . . . . . . . . . . . . . . . . 161

The Sequential DBSL Trace . . . . . . . . . . . . . . . . . 161The Deadlock Trace. . . . . . . . . . . . . . . . . . . . . . 162

Trace Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . 164The Database Notification Log. . . . . . . . . . . . . . . . . . 165The Database Diagnostic Log . . . . . . . . . . . . . . . . . . 166DB2 Logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

iv

The Dump Directory . . . . . . . . . . . . . . . . . . . . . . . 168The DB2 Help Center . . . . . . . . . . . . . . . . . . . . . . 169Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Chapter 9: New Features . . . . . . . . . . . . . . . . . . . . . . . . . . 171Workload Management (WLM) . . . . . . . . . . . . . . . . . 171

Workloads and Service Classes . . . . . . . . . . . . . . . . 172Critical Activities . . . . . . . . . . . . . . . . . . . . . . . 173

BI Administration . . . . . . . . . . . . . . . . . . . . . . . . 174BI Data Distribution . . . . . . . . . . . . . . . . . . . . . 174The MDC Advisor . . . . . . . . . . . . . . . . . . . . . . 176

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

v

Foreword

This is a remarkable book, written by IBM experts who have in-depth knowledgeabout SAP on DB2. The authors have their profound experience not only fromtheir work with many customers who adopted DB2 for their SAP applications,but also from their very close cooperation with SAP development. Based on theanalogy of a pilot’s need to know about the controls of his aircraft, this booktakes you through the entire world of DB2 monitoring and administration. Youwill find it a useful introduction if you are new to SAP on DB2, and you will alsobe 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 controlsto 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 ZieglerSAP Manager

DB2 LUW Platform Development

vi

Chapter 1

The SAP DBA CockpitA 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 affect

the flight of the airplane. Balancing lift and drag, speed and altitude, yaw andwind are all important parts of a safe, comfortable flight. However, a hugeamount of technology also operates and manages the individual aircraft compo-nents. A pilot who flew the aircraft without knowing what the technology doescould disrupt automated flight operations. Similarly, if the technology were notleveraged specifically for the aircraft flight requirements, flight operations couldbecome 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

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 uniqueSAP 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. Databaseadministration consoles were too generic to focus on application-specific require-ments, and application administration consoles were not specific enough to fullyleverage 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 asingle 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 thesame dialog screens. The most important information for SAP administrators isnow 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 theright, 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 theDBACOCKPIT transaction. This can also be displayed at any time by clicking theSystem Configuration button, just above the left navigation menu.

2

CHAPTER 1: The SAP DBA Cockpit

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:

• Performance—Display performance statistics for monitoring databasememory, disk I/O, application resource usage, query execution, and more.

• Space—Review historical and real-time storage usage for table spaces,containers, and individual tables, and perform administrative functions toalter the logical and physical storage layout of the SAP database.

• Backup and Recovery Operations—Review historical backup and logarchival information, and real-time log file system statistics.

• Database Configuration—Display and update database configurationparameters, configure partition groups and buffer pools, and adjustmonitoring and automatic maintenance settings.

3


Figure 1.1: The SAP DBA Cockpit for DB2 has a large display area on the right and a smallnavigation menu on the left.

• Job Scheduling—Create, schedule, and monitor periodic jobs from aplanning calendar.

• Alert Monitoring—View key database health alert statuses and messages,and enable notification for database alert threshold violations.

• Diagnostic Functions—View and filter messages from the databasediagnostic logs, view optimizer access plans and recommended indexes forSQL statements, run SQL commands, view DB2 online help, and more.

• Workload Management—Set up, maintain, and monitor the differentworkloads and service classes configured for the SAP system in DB2’sWorkload Management.

• BW Administration—Change data distribution and analyzeMulti-Dimensional Clustering in partitioned SAP NetWeaver BWdatabases.

The left navigation frame of SAP Enhancement Package 1 for SAP NetWeaver7.0 contains two additional screens. The first entry links the user directly into theDB2 LUW main web page in the SAP Developers Network (SDN), allowing theuser to browse the SDN from directly within the SAP GUI. The other screenlaunches the new web browser-based DBA Cockpit. Several of the new featuresof 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 StartWebDynpro GUI menu entry launches the main page of the web browser-basedDBA 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 latestreleases of SAP and DB2. This book illustrates the latest features available in theDBA Cockpit in SAP Enhancement Package 1 for SAP NetWeaver 7.0.

4


Central Monitoring of Remote SystemsThe DBA Cockpit allows administrators to configure connections to every SAPsystem from a single DBA Cockpit session. A Solution Manager instance or astandalone SAP NetWeaver instance can be installed for administrators to use forcentral monitoring and administration. You should keep this SAP system at themost current SAP release level, to maximize backward compatibility and makethe most advanced DBA Cockpit features available for all systems.

Remote connections can be established using the database information from theSystem 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 theSLD System Import button. This provides a graphical interface to select and reg-ister the unregistered SAP systems into the cockpit. This allows the entire SAPsystem landscape to be centrally managed in the SLD, and provides a simple wayto register any new or changed systems in your central DBA Cockpit.

Alternatively, click the Add button to manually register new databases into thecockpit. This allows administrators to register even non-SAP systems. Therefore,the DBA Cockpit can provide a single administrative GUI for every SAP andnon-SAP database in your IT landscape.

SummaryThe 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 asingle point of administration for every DB2 database in your organization. TheSAP DBA Cockpit for DB2 gives administrators fast and easy access to all of themost important DB2 database information, all from within the familiar look andfeel of SAP GUI.

5


Chapter 2

Performance MonitoringAre 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 the

SAP 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 screensand tabs for important, related information:

• Performance: Partition Overview

• Performance: Database Snapshot

• Performance: Schemas

• Performance: Buffer Pool Snapshot

• Performance: Tablespace Snapshot

6

• Performance: Table Snapshot

• Performance: Application Snapshot

• Performance: SQL Cache Snapshot

• Performance: Lock Waits and Deadlocks

• Performance: Active Inplace Table Reorganizations

• Performance: History—Database

• Performance: History—Tables

• Everything needed by a database administrator is only a click or two away.

Performance: Partition OverviewDatabase Partitioning Feature (DPF) is one of the key DB2 features for improv-ing the performance of SAP NetWeaver BW systems. DPF allows a SAPNetWeaver BW database to scale out incrementally on lower-cost hardware, orgrow 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 SQLstatements can be “divided and conquered.” If the workload is balanced evenlyacross 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 maximizesperformance.

To access the partition overview, shown in Figure 2.1, click Performance�Partitions in the navigation frame of the DBA Cockpit. This displays the mostimportant performance statistics for each active partition in the current SAPNetWeaver BW system. For each partition, this overview shows the total numberand size of the buffer pools, key I/O read and write characteristics, SQL state-ment executions, and package cache statistics. Ideally, a well-balanced systemwill have similar values on each partition for all of these characteristics.

Probably the most important performance indicator is buffer pool hit ratio. Thiscan 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

the database snapshot data from that partition. On each partition, the index hitratio 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 orheavily accessed tables across all partitions. However, for very large systemswith a very high number of partitions, it might be impractical to distribute tablesthinly across all partitions. In this case, heavily accessed tables can be balancedequally across subsets of partitions. For example, one heavily accessed InfoCubecan reside on partitions 1 through 9, and another heavily accessed InfoCube canreside 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 thatthe database leverages the full processing capacity of all partitions equally.

8


Figure 2.1: The performance characteristics of the DB2 database partitions are shown inthe Performance: Partition Overview screen.

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 abigger package cache than other data partitions. Package cache quality should be95 to 98 percent on each partition.

Performance: Database SnapshotThe 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 sincethe last system reset. The system can be manually reset at any time by clickingthe Reset button at the top of the screen. To the right of the Reset button, youwill find a Since Reset button and a Since DBM Start button. These toggle thestatistics between the values since the last reset, and the values since the start ofthe database manager (the DB2 instance).

9


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 operationsin the background (asynchronous), performance generally improves. On the otherhand, 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 availablein 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 qualityfor the entire database should be above 95 percent, with data hit ratios above 95percent and indexes hit ratios above 98 percent. Hit ratios can be improved by in-creasing buffer pool size, compressing the database, improving cluster ratios forSAP NetWeaver BW, or by optimizing buffer pool allocation, which can be doneautomatically by the DB2 Self Tuning Memory Manager (STMM).

10


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

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 awell-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, abuffer pool miss occurs, and the page must be read from disk, which is called aphysical read. The buffer pool quality is the ratio of the number of page requestsfound in the buffer pool to the total number of logical read requests.

Physical reads and writes are unavoidable, because new transactions are alwaysreading 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 bufferquality. 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 behalfof the client connection, and asynchronous I/O is performed by the DB2prefetchers and page cleaners. The statistic labeled “Average Time for the Physi-cal Reads and Physical Writes” on the DBA Cockpit indicates the I/O subsystemperformance. 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 performingoptimally.

Asynchronous reads are performed in the background by the DB2 prefetchers,which anticipate the needs of the applications, and load, from disk into bufferpools, the pages that are likely to be required. In most cases, the prefetchers readthese 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 datafor 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 occursmost frequently during random requests for single pages, which are common inOLTP applications operating on single rows of data via an index. However, thismay also occur if the prefetchers are all busy with other prefetch requests.

11


Each synchronous read request results in I/O wait at the client, because the agentprocessing the SQL statement must directly perform a read from disk before itcan continue query processing. For single-row access, it is just as efficient for theagent to read the single page itself. However, for prefetch requests involvingmultiple pages, it is far more efficient to have the prefetchers read these pages inthe background.

A properly configured system performs most read operations asynchronously andminimizes overall system I/O wait. If a large percentage of read operations aresynchronous, 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 thesystem 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, dependingon 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 agentsto 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 StandardPage Cleaning.

Standard Page CleaningUsing Standard Page Cleaning, page cleaners will asynchronously write data todisk whenever one of the following occurs:

• CHNGPGS_THRESH is exceeded.—The database configuration parameterCHNGPGS_THRESH specifies the maximum percentage of changed pagesallowed within a DB2 buffer pool. Once a buffer pool reaches thispercentage of changed pages, the DB2 page cleaners are signaled to writethose changed pages to disk in the table space containers. This parameteris set to 40 percent by SAPinst. To find it in the cockpit, clickConfiguration� Database� Optimization.

12


• SOFTMAX is exceeded.—The database configuration parameter SOFTMAX

specifies the maximum total size of changed pages in the buffer pool thathave not yet been written to disk. You can find this parameter in thecockpit by clicking Configuration� Database� Logging. It isspecified as a percentage of one log file in size, and is set to 300 bySAPinst. This means that the buffer pool can contain a maximum of threelog files’ worth of changes (300 percent of one log file). Once thisparameter is exceeded, the database enters a log sequence number (LSN)gap situation, and the page cleaners are signaled to begin writing thosechanged pages from buffer pool to disk in the table space containers.

Whenever the above two thresholds are exceeded, the DB2 page cleaners beginwriting 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, whichis not currently used by default by SAP. Performance testing has indicated thatStandard Page Cleaning currently performs marginally better for most SAPworkloads. However, for OLTP systems with very update-intensive workloads,performance might improve slightly by enabling Proactive Page Cleaning in theDB2 profile registry:

db2set DB2_USE_ALTERNATE_PAGE_CLEANING=ON

Using Proactive Page Cleaning, the page cleaners no longer respond to theCHNGPGS_THRESH parameter. Rather than keeping a percentage of the bufferpool 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 readagain soon. If either a LSN gap occurs, or the number of good victim pages dropsbelow an acceptable threshold, the page cleaners are triggered. They proceed tosearch the buffer pool, write out pages, and keep track of these new good victimpages. The page cleaners will not only write out pages in a LSN gap situation,

13


but will also write pages that are likely to enter a LSN gap situation soon, basedon the current level of activity.

When the database agents need to read new data into the buffer pool, theprefetchers read the list of good victim pages, rather than searching through thebuffer pool for victims. This tends to spread writes more evenly, by writingsmaller amounts more frequently. By spreading the page cleaner write operationsover 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 marginallybetter using Standard Page Cleaning, we recommend using it for all SAP applica-tions. Future changes to Proactive Page Cleaning might increase its usage withinSAP. For now, though, if you have a uniquely heavy-update workload that youthink might benefit from Proactive Page Cleaning, test the change thoroughly todetermine the effect on performance before enabling it in the production system.

The No Victim Buffers element in the DBA Cockpit can help evaluate whetheryou have enough page cleaners when using Proactive Page Cleaning. This ele-ment displays the number of times a database agent was unable to findpre-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 thiselement is high relative to the number of logical reads, the database page cleanersare not keeping up with the changes occurring in the database, and more pagecleaners are likely required.

If Proactive Page Cleaning is off, and you are using Standard Page Cleaning, theNo Victim Buffers monitor element can be safely ignored. In the default configu-ration, Standard Page Cleaning is triggered by CHNGPGS_THRESH and SOFTMAX,and the prefetchers will usually search the buffer pool to find suitable victimpages. Therefore, you can expect this monitor element to be large.

Synchronous WritesIf the database must read data from disk into a buffer pool, and there are no freepages remaining in the buffer pool, DB2 must make room, by replacing existing

14


data pages (victims) with the data pages being read. If these victim buffer poolpages contain changed data, these pages must be written to disk before they areswapped 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 writeoperation must occur synchronously, before the buffer pool page can bevictimized (replaced with a new page from disk). A large percentage ofsynchronous write operations indicates that the DB2 page cleaners are notoperating effectively. This might be due to slow disks or unbalanced I/O in thestorage 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 tablespaces, displaying the temporary logical and physical reads for both data and in-dexes. The logical reads display the total number of read requests for temporarytable space data. The physical reads display the number of read requests thatwere 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 BWsystems might show larger temporary table space I/O, but large values here mightstill indicate inefficient queries or a need to create higher-level aggregates toimprove query performance.

The Catalog Cache and Package Cache

The second tab in the DBA Cockpit database performance monitor is the Cachetab, shown in Figure 2.3. This tab displays the details for the database catalogcache and the package cache.

15


The Catalog Cache

The catalog cache is a portion of database memory that is dedicated to cachingaccess to table descriptor and authorization information from the database systemcatalog tables. These table descriptors include the table information used by DB2during query optimization. When this data is accessed, it is first read from diskinto the catalog cache, and then the database agents requesting this data read itfrom memory. Therefore, high hit ratios on this buffer are important for perfor-mance. If the most frequently accessed system catalog details can be cached inmemory, unnecessary disk reads can be avoided.

A high catalog cache hit ratio is even more important in multi-partition SAPNetWeaver BW systems. In a partitioned SAP NetWeaver BW system, thesystem 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 catalogcache on partition 0, and then sends the information to the catalog cache on theother partition. Caching most of the system catalog information at each partitionavoids both disk I/O and network I/O, and reduces the workload on theAdministration 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 nooverflows. If overflows occur, DB2 must allocate more memory from databaseshared 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.

from memory, and the cache is reduced to its configured size. This involves extraoverhead 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 togetherwith the cache quality to determine whether or not the default size is adequate foryour workload. The catalog cache size is set by the CATALOGCACHE_SZ databaseconfiguration parameter. To view or change this parameter in the DBA Cockpit,click Configuration� Database� Database Memory.

The Package CacheThe 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 isexecuted multiple times, the access plan can be read from memory, which avoidsrepeating 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 optimizeoverall performance, based on your changing workload. Package cache hit ratioshould remain above 98 percent, and overflows should not occur. The packagecache size is set by the PCKCACHESZ database configuration parameter. To viewor change the package cache size in the DBA Cockpit, click Configuration�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


cache size set to AUTOMATIC, and let DB2 STMM configure the size based onyour current available memory and optimal overall system performance.

Asynchronous I/O

The third tab in the Database Performance Monitor is Asynchronous I/O, shownin Figure 2.4. This displays information on the I/O reads and writes that usebackground read and write operations to perform disk I/O to and from the DB2buffer pools, using the DB2 prefetchers and page cleaners. Asynchronous I/O op-erations anticipate application I/O requirements, and operate in the background tominimize 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. Thenumber 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 andNUM_IOCLEANERS for page cleaners. Both are found in the cockpit underConfiguration� Database I/O.

New SAP installations default both of these parameters to automatic. This allowsDB2 to calculate the optimal number of prefetchers and page cleaners, when thedatabase 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 registryvariable, 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 alwaysgreater or equal to the number of disks available to any one table space, whichenables asynchronous prefetch requests to drive every available disk in parallel.

18


The formula for page cleaners ensures that they are evenly distributed across allpartitions in a partitioned SAP NetWeaver BW system, and that there are nevermore page cleaners than CPUs. This prevents asynchronous page cleaning fromaffecting normal transaction processing performance. Ideally, both asynchronousread and write times should be less than 5 ms.

Direct I/ODirect 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 smallestbeing a 512-byte disk sector. Direct reads always occur when the database readsLONG 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/Oshould 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 requestshould 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.

Real-Time Statistics (RTS)The concept of Real-Time Statistics (RTS) was first introduced in DB2 9.5. SAPEnhancement Package 1 for SAP NetWeaver 7.0 now contains a performancemonitoring screen for this new DB2 feature. RTS allows DB2 to trigger eitherstatistics collection or estimation during query compilation, if table statistics areeither absent or stale. If statistics collection would exceed 5 seconds, it is done inthe background. Otherwise, it may even be done synchronously during querycompilation, 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 forqueries, and that performance is never excessively bad due to stale statistics.

The information available in the DBA Cockpit, shown in Figure 2.6, is valuablefor determining the performance impact of RTS. It might suggest the need formore 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 isnot buffered in memory by the DB2 buffer pools.

Figure 2.6: The Real-Time Statistics tab shows details related to RTS statisticscollection.

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 cachemight be required.

Asynchronously collected statistics occur when synchronous statistics collectionduring 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 fromnewer statistics.

Synchronous statistics collection occurs when a RUNSTATS is triggered to collectstatistics during query compilation. This RUNSTATS may or may not be sampled,depending on the RUNSTATS profile for the table and the time estimate for statis-tics collection. The end user might experience a maximum of 5 seconds extratime 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 sampled RUNSTATS table or index scan consumes too much time,then new metadata stored in the data and index manager system catalog tables isused to estimate the current table statistics. Those statistics are immediately madeavailable in memory for all other queries to use until a RUNSTATS is performedon the table. In the cockpit, statistics estimation is displayed by the number ofstatistics collections during query compilation, and the time spent during querycompilation.

Locks and DeadlocksWhenever table records are accessed, DB2 places locks on those records to main-tain transaction integrity and ensure that two transactions cannot update the samedata at the same time. The type of lock used by DB2 depends on the isolationlevel defined for the application accessing those records. Traditional DB2 lock-ing involves the following isolation levels, ordered by increasingly restrictivelocking:

21


• 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 beingaccessed by a cursor. If that record contains an uncommitted update, the readof that row must wait until that update is committed. This ensures that theapplication cannot read uncommitted data, and that the current position of thecursor 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 ofwork is committed or rolled back. This ensures that any row read during aunit of work (UOW) remains unchanged until the UOW commits, and thatthe application cannot read uncommitted changes from other transactions.

• RR (Repeatable Read)—Read-only locks are placed on all recordsreferenced during the processing of the current UOW. This includes allrows 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 uncommittedupdates 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 mayinvolve multiple database transactions, each of which is committed into the SAPupdate 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 readcommitted 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 entireSAP transaction.

22


One potential exception to the UR default isolation level occurs when accessingcluster or pool tables. Since reading a single logical row may involve readingmultiple 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 allphysical rows, SAP will read again, first trying CS, and if necessary, finallyreading with RS, which will guarantee read consistency for all physical rows inthe logical record. However, inconsistent reads on logical rows using UR rarelyoccur, 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 therow locks exceeds the size of the lock list, DB2 will convert multiple row lockson a single table into a single table lock. This lock escalation frees up space inthe lock list for other row locks. However, it can also reduce concurrent access tothe table involved in the escalation. At best, this might reduce performance forapplications accessing that table; at worst, it might result in increased lock waitsor deadlock scenarios in other concurrently running applications.

Normal lock escalations allow read access to the locked tables, but force writes towait for the application holding the lock to commit. Exclusive lock escalationsalso disallow reads, thereby reducing concurrency even further. Therefore,administrators should try to completely avoid lock escalations, by ensuring thatthe lock list is large enough to contain the locks for the concurrent activity in theSAP system.

The size of the lock list is set by the LOCKLIST database configuration parameter,which can be found in the cockpit under Configuration� Database�Self-Tuning Memory Manager. Lock list utilization can be calculated using thelock_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 theLocks and Deadlocks section of the SAP DBA Cockpit for DB2, which is shownin Figure 2.7.

By default, SAPinst enables DB2 STMM. Therefore, LOCKLIST is set toAUTOMATIC, allowing DB2 to dynamically adjust the size of the lock list to avoid

23


lock escalations and optimize overall system performance. Normally, lock esca-lation is extremely rare for databases with a properly configured lock list or fordatabases using STMM.

Another parameter automatically tuned by STMM is MAXLOCKS. This specifiesthe 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. UsingSTMM, DB2 can automatically adjust this percentage, depending on the numberof concurrent transactions and the number of locks held by each concurrent unitof 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 tobe lower to avoid a scenario where one application consumes most of the locklist, while the others quickly run out of space in the lock list and are forced to es-calate. Properly configuring the LOCKLIST and MAXLOCKS parameters or usingSTMM will prevent lock escalations.

24


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

If lock escalations are occurring, then abnormally large values can be expected forthe 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 agreater possibility that one of these waiting applications will already be holding alock that will be requested by the escalating application. This would result in adeadlock, with each application waiting for locks already held by the other.

Large lock wait values without lock escalations or deadlocks might indicate thatcustom applications are not efficiently committing their units of work. Customapplications should try to hold locks for as little time as possible, by performingefficient 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 waitscenarios.

A lock timeout occurs when an application waits to acquire a lock for longer thanthe LOCKTIMEOUT database configuration parameter, which is set to 3,600 sec-onds (1 hour). This default value is much larger than any application should berequired to wait for locks. If a lock wait occurs, an application has probably hungin 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.

LoggingThe transactional log files of the database maintain database integrity by contain-ing a physical copy, on disk, of all committed database transactions. When data isupdated, the changes are made directly in the DB2 buffer pool, and logged in theDB2 log buffer. When a transaction commits, each entry in the log buffer mustbe successfully written from the log buffer to the log files before the commit

25


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 writesto the DB2 transactional log files.

DB2 contains two kinds of log files: primary and secondary. The number andsize of these log files are set with the LOGPRIMARY, LOGSECOND, and LOGFILSZ

database configuration parameters. Primary log files are pre-allocated when thedatabase is created. Secondary log files are allocated on demand, whenever ac-tive transactions exceed the total size of the primary log files. Therefore, the totalsize 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 either circular or archive logging. Circular log-ging reuses primary log files once they no longer contain log records required forcrash 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-timerecovery is always possible. When a primary log file becomes full, it is archived(copied) by DB2 to the locations set in the LOGARCHMETH1 and LOGARCHMETH2

database configuration parameters. Once the log file is no longer needed forcrash recovery, it is renamed to the next log file sequence number, and its headeris 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 logfile becomes full, and a transaction spanning multiple log files rarely incurs theoverhead of allocating the next log file.

The Logging tab, shown in Figure 2.8, displays the number and size of log filesavailable and allocated in the system. If the database is using secondary logs, youcan see the number currently allocated, and the maximum secondary log filespace used by the database.

26


This information can help determine if the primary log space is adequate for yourcurrent workload. In general, we recommend that the log file system should be1.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 forinactive (online archive) logs waiting to be archived, or new logs being formattedfor 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 thenumber of primary log files or increasing the log file size. First, always ensurethat the log file system is large enough to contain all of the configured logs. Thecockpit also displays the database application ID with the oldest uncommittedtransaction. This can help identify long-running transactions that might needattention.

The Log Buffer Consumption section is valuable for determining the effective-ness of page cleaning. The LSN Gap value specifies the percentage of theSOFTMAX 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.

includes pages that have been changed in a buffer pool by both committed anduncommitted 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 ofSOFTMAX occupied in the log files by committed transactions. Statements in thisRestart Range will need to be rolled forward during crash recovery. Again, if thisis greater than SOFTMAX, more page cleaners might be required.

The I/O characteristics of the log file system are also provided. The Log PagesRead displays the physical log file page reads required during rollback operationsin the database, and the Log Pages Written displays the pages of transactionaldata written into the log files. The transaction commit time depends on the logfile system’s write performance. Therefore, having the fastest log file systempossible minimizes dialog response time. A well-performing system should havelog file system write times below 2 ms.

Ideally, very few log buffer overflows should occur. This indicates the number oftimes any database agent has waited for log buffer flushes in order to write intothe log buffer. These can occur when large transactions produce a series of logrecords larger than the buffer, or when high transaction volumes consume the en-tire buffer with many smaller log records simultaneously. When this occurs, allin-flight transactions must wait for the log buffer to be written to disk before theycan continue writing log records into the buffer. This introduces I/O wait into allin-flight transactions and hurts performance. For optimal performance, the logbuffer should be large enough to avoid overflows during normal workloads.

CallsThe Calls tab, shown in Figure 2.9, contains a summary of the different types ofSQL statements issued, and their performance impact on the SAP system. Thisdisplays the number of rows read, deleted, inserted, selected, and updated. Thesecan be compared to the number of DML and DDL statements executed and theirexecution time, to understand the average number of rows read per SQL state-ment, and the time spent processing those statements within the database.

28


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 ofdata 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 relevantrows 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 ifthis 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, thiscounts as a small overflow. If the number of small overflows is greater than 10percent of the total overflows, avoiding these small overflows with a larger sortheap 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, ahash loop results. When this occurs, the intermediate join of that one section ofdata 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 theload on the database.

For performance reasons, always try to minimize the number of hash loops andhash join overflows. With DB2 9.5, the sort heap memory parameters default toautomatic settings using the DB2 Self-Tuning Memory Manager. This allowsDB2 to automatically adjust the available sort heap memory to avoid unnecessaryhash join overflows or hash loops.

SortsThe Sorts tab, shown in Figure 2.10, displays memory usage and overflows fromdatabase sorts. The Sort Overflows value is probably the most important one onthis 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 memoryheaps are properly configured. DB2 9.5 defaults to automatic shared sort memoryand the Self-Tuning Memory Manager. This allows DB2 to manage sort memoryallocation based on overall system requirements, which avoids unnecessary sortmemory allocation and prevents most sort overflows.

30


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

XML StorageThe 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 catalogedinto the cockpit, or for user tables created manually by SAP customers.

Performance: SchemasThere 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 defaultto SAP<SAPSID> for ABAP systems, and SAP<SAPSID>DB for Java systems. Theonly other users who generally connect are the SAP admin user, <SAPSID>ADM,and the DB2 instance owner, DB2<DBSID>.

The Schemas dialog screen can be used to identify the activity of usersconnecting to any database partition from outside the SAP application. I/Operformance characteristics of reads and writes can be monitored for eachschema.

Performance: Buffer Pool SnapshotThe default installation of SAP on DB2 creates all table spaces using 16KBpages. By default, the only visible buffer pool is IBMDEFAULTBP, which is alsocreated with 16KB pages. If other table space sizes are created, then other bufferpools corresponding to each unique page size must be created, too. However,SAP recommends keeping everything in your system at a uniform page size of16KB. 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 thedata, index, and temporary table spaces on all database partitions. If different

31


buffer pools have been created for different database objects, this provides aneasy interface to compare the individual statistics for each buffer pool on eachdatabase 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 poolsnapshot for that particular buffer pool on that particular partition, as shown inFigure 2.11. This displays the data and index read statistics, buffer quality, andutilization state of the buffer pool. It also includes tabs showing the detailedasynchronous and direct I/O operations, and performance characteristics for thisbuffer 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 individualbuffer pool.

As a safety net, DB2 is also pre-configured with hidden buffer pools for eachpossible page size (4K, 8K, 16K, and 32K). These hidden buffer pools ensurethat 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 databaseactivation, or if anything in the database performs I/O using a page size without acorresponding user-defined buffer pool. Since these hidden buffer pools are only16 pages in size, performance will likely suffer if they are used. An entry islogged 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 arecritical for performance. The performance statistics for each individual tablespace can help administrators identify data hot spots or inadequate buffer poolconfigurations. The Performance: Tablespace Snapshot screen, shown in Figure2.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 abuffer pool quality of at least 95 to 98 percent. The frequently accessed index ta-ble spaces (with names ending in I) 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 haveslower I/O, you might simply have slow disks. However, this might also be asign of disk contention, especially if more frequently accessed table spaces areslower than others. To improve performance, spread the data across a greaternumber of physical disks, or move one or more frequently accessed tables to anew 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


Similar to the previous buffer pool snapshot, double-clicking any row displays amore 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 SnapshotPage reorganizations and overflow record accesses are two key performance indi-cators for individual tables. Page reorganizations occur when an insert or updateis done to a data page that contains enough free space for the new data, but thefree 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 theend of the page, and then the insert or update proceeds. This extra overhead canhurt insert and update performance. However, if an update is being done, and apage reorganization cannot reclaim enough contiguous space for the updatedrow, the row must be moved to a new page. An overflow record (or pointer) isthen 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.

page. When this row is accessed, DB2 must perform two I/O reads instead ofone: the first to read the pointer from the original location, and the second to readthe 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-clickingany 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 fromSingle 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 canbe 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 separatingthese tables into different table spaces on different sets of physical disks.

35


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

Performance: Application SnapshotThe 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, theirbuffer 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 forthat single application. Shown in Figure 2.14, this snapshot displays all of the keyapplication statistics, organized conveniently into unique screen tabs.

The first Application tab describes the application on the host, and displays theclient 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.

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 thedatabase default to automatic, and are dynamically maintained by DB2 to opti-mize memory utilization and performance.

The Buffer Pool tab displays the application’s detailed data, index and temporarytable space read statistics, and buffer pool quality. The read statistics can indicatethe I/O efficiency of the queries in this application. The performance details ofthe non-buffered I/O (e.g. LOB access, backup and restore) are shown in theDirect 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 thecurrently selected application. If an application is holding too many locks, caus-ing lock escalations, or involved in deadlocks, consider looking more closely atthe application coding and SQL. A properly coded application will hold as fewlocks as possible and commit as frequently as possible, so that locks are releasedquickly. An application should commit as frequently as possible, and not performunnecessary calculations inside SQL units of work. The SQL statements shouldalso try to reduce the amount of data accessed during a query, and only return therows of relevance for the application.

The Unit of Work tab displays the length of time and log space consumption ofthe 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 currentSQL statement being executed. This screen also contains buttons to load theoptimizer execution plan for the statement, or to view the ABAP source code forthe program executing this SQL statement. These tools can be used to analyze theprogram logic and SQL execution plans, to ensure efficient SQL and indexed ac-cess to the data pages being fetched.

Performance: SQL Cache SnapshotIf administrators are going to spend their valuable time tuning the performance ofindividual queries, then it makes sense to focus on the queries that most affect the

37


system. The Performance: SQL Cache Snapshot screen, shown in Figure 2.15, al-lows administrators to easily identify the queries that are consuming the largestamount 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 themost execution time. The buffer pool hit ratio is given for each query, to identifyhow much disk I/O the query is causing.

The next few columns provide valuable information about SQL query quality andI/O quality. The Rows Read/Rows Processed column gives a ratio of how manyrows must be read to identify the rows required for the final result set. The BPGets/Rows Processed column indicates the number of pages that must be ac-cessed from the buffer pool to read the final result set. The BP Gets/Executioncolumn provides the number of pages read from buffer pool per query execution.If the number of rows read or the ratio of rows read to rows processed is high, theindex advisor might help to identify a better index, to reduce the number of rows

38


Figure 2.15: The SQL Cache Snapshot shows the execution time and resource consump-tion of queries that have run in the system.

evaluated by the query. If the BP gets are high, clustering the table differentlymight improve performance, or a table reorganization might help to reduce thenumber of pages read from disk.

The last few columns of the Performance: SQL Cache Snapshot screen provide in-formation on sorting. A query that displays a large number of rows written indi-cates sort overflows to disk in the temporary table space. The cockpit also displaysthe total number of sorts, number of sort overflows, and total time spent sortingduring the query. If sort overflows are occurring, and the total sort time is a signifi-cant portion of the average execution time, further analysis of the query, indexes,and potentially sort parameters might be required to try to reduce sort overflows.

Click the Explain button, and the optimizer execution plan is displayed, showingthe query cost and join methods. From there, click the Details button to open anew window with all of the detailed optimizer data, including all indexes and da-tabase objects accessed, join methods, and cardinality estimates for each join.Click of the Index Advisor button, and the DB2 Advisor is run to suggest new,optimal indexes to optimize data access for this query. (Both the Optimizer Ex-plain and the Index Advisor interfaces are explained in detail in Chapter 8.)

Performance: Lock Waits and DeadlocksA lock wait occurs when one application acquires a lock on a database object,and then another application requests an incompatible lock on that same databaseobject. When this occurs, the second application must wait for the first to releaseits lock, through either a commit or rollback. The amount of time applicationswait to acquire locks is the lock wait.

If the first application were to then request a lock already held by the second, thetwo applications would enter a deadlock scenario. In this state, both applicationsare waiting for locks held by the other, and neither can proceed. Deadlocks canaffect any relational database. They are usually caused by infrequent or missingcommit statements within custom applications.

DB2 resolves deadlocks automatically, by periodically checking for their exis-tence, and when found, randomly selecting one of the deadlocked applications to

39


rollback. The frequency of deadlock checks is set by the database configurationparameter DLCHKTIME, which defaults to 300,000 ms (5 minutes) in SAPNetWeaver 7.0 systems. The rolled back application fails with a SQL0911N error,and all of its locks are released. This allows the other application to acquire itslocks and proceed.

The active lock waits and deadlock scenarios can be seen through the Perfor-mance: Lock Waits and Deadlocks screen shown in Figure 2.16. The screen liststhe database agents and lock types involved in all active lock waits and dead-locks, and includes buttons to view the last SQL statement from each unit ofwork involved in these scenarios. This provides real-time analysis of the applica-tions causing locking issues.

40


Figure 2.16: The Lock Waits and Deadlocks dialog displays the current lock wait and dead-lock scenarios that are actively occurring in the system.

Performance: Active Inplace Table ReorganizationsReorganizations of large tables can take a long time to run. DB2 provides theability to perform online table reorganizations in-place in the table space, so thatit is not necessary to consume the table size in temporary table space to performthe reorganization. The Performance: Active Inplace Table Reorganizationsscreen allows the DBA to monitor and administer any active in-place reorganiza-tion jobs. There are even buttons to allow the DBA to pause, resume, or suspendactive table reorganizations, if necessary.

Performance: History–DatabaseCatching performance problems in action is a reactive process. All administratorsshould try to be proactive about monitoring performance trends and taking actionto prevent potential problems before they occur. Having easy access to these his-torical trends makes proactive analysis much easier, and SAP can be configuredto collect this historical information when the system is registered into the DBACockpit.

The Performance: History–Database screen shown in Figure 2.17 displays manykey historical performance indicators. The main screen displays the average readand write times, the number of reads and writes, and the number of commits androllbacks, as well as information on lock waits, lock escalations, and deadlocks.This information can be displayed in two ways. Select Total Day to display theaverages and totals for each day over the configured monitoring period. SelectPeak to display the maximum value for the day for all measured monitor ele-ments. This gives a simple way to identify average and peak performance trendsover time.

41


Clicking any single day in the list displays the details gathered for each monitorelement periodically throughout the day. This can be viewed in two differenttabs. The Snapshot tab provides the details of each individual sample throughoutthe day. The Interval tab displays only deltas. Therefore, it will contain only en-tries for times when one or more monitor element value changed from its previ-ous value.

Performance: History–Tables

The performance history of individual tables is also available for proactive plan-ning. For each table on each database partition, the Performance: History–Tablesscreen displays the rows read and written, overflow records accessed, and pagereorganizations. This information can be displayed for each day, week, or month.Both short- and long-term trends for table access can be easily analyzed, provid-ing the DBA with the information needed to proactively plan for system changesto accommodate changing workloads.

42


Figure 2.17: Daily historical performance data can be analyzed in this dialog.

Performance WarehouseThe new SAP Database Performance Warehouse provides an integrated historicalperformance analysis model for both the database and the SAP applications. Da-tabase performance data is extracted and loaded from all SAP systems into a cen-tral SAP NetWeaver BW warehouse. Historical performance data can then bemined, trended, and analyzed, using powerful SAP NetWeaver BW interfaceswith charts, dashboards, and drill-down capabilities.

The ABAP cockpit contains a Reporting link for analyzing performance data anda Configuration link for setting up the Performance Warehouse reporting parame-ters. The Reporting screen links directly into the Performance ReportingWebDynpro. An example of the data is given in Figure 2.18. This illustrates his-toric buffer pool quality over a two-week period. This data clearly displays recur-ring trends that can identify areas that might benefit from tuning.

Only this brief introduction to the Performance Warehouse will be given in thisbook. More documentation on the Performance Warehouse can be found on theSAP Service Marketplace or SDN.

43


Figure 2.18: The SAP Performance Warehouse displays detailed reports on historicalperformance and resource consumption trends.

SummaryThe performance section of the DBA Cockpit provides a comprehensive, singleinterface for all DB2/SAP database performance monitoring and tuning. All ofthe most important information is easily accessible, and displayed in an intuitive,meaningful way.

Since all the information is in one location, it is easy to drill down from databasemonitors, to table space and table monitors, to application monitors, and evenright down to SQL statement monitors. Administrators can start with a wide fo-cus and methodically narrow that focus to the exact source of the problem underinvestigation. The best part is that the tool is part of SAP, so both SAP basis anddatabase administrators can leverage this powerful tool in a familiar interface, toget the best performance from their SAP systems.

44


Chapter 3

Storage ManagementFlying Efficiently with Heavy Cargo

Properly managing the volume of data within your SAPsystem is key for efficient performance. The DBA Cockpit

gives you all of the storage statistics and growthcharacteristics you need to optimize database

storage, now and for the future.

Storage is the most frequently overlooked aspect of database performanceconfiguration, yet it can significantly contribute to how well a database per-

forms, because disk I/O is the slowest part of any computer interface. A poorlyconfigured data layout will ultimately be the constricting bottleneck, regardlessof how well the SQL statement is formed or what access plan is chosen.

DBAs can spend a lot of time designing and planning the layout of table spacesfor a storage subsystem. Today’s advanced storage subsystems offer manychoices on how physical disk volumes can be grouped into RAID arrays, andwithin these arrays, how logical volumes (LUNs) can be defined and made avail-able as usable storage to the database. Designing the placement of table spacescan be more like an art than a science. The problem in spending so much time onan elaborate design is that it is only appropriate for the quantity of data and

45

workload at a given point in time. As the system matures and evolves, so mustthe storage layout.

As companies adapt their SAP systems for future business needs, such as addingadditional modules, the amount of data inevitably grows. Therefore, the data ac-cess pattern will evolve, rendering the initial data layout design obsolete. To keepthe system running optimally, time-consuming and intrusive administrative tasksmight be required regularly, to re-evaluate and re-optimize the data layout. Often,a simpler, more generic storage layout, like that provided by DB2’s automaticstorage feature, provides a better solution for high performance and low mainte-nance throughout the entire lifetime of the SAP application.

DB2 table spaces store their data in physical storage objects known as containers.A table space can span one or more containers. Data within the table spaces arestriped evenly across all containers for that table space.

DB2 uses two types of table space concepts: System Managed Space (SMS) andDatabase Managed Space (DMS). With SMS, the storage allocation within thetable space containers is managed by the operating system (OS). Containers areOS directories, and a unique file exists in each container for each database objectresiding in that table space. By default, I/O to these table spaces will be bufferedby the file system, and the sizes of the files in the containers will be extended orreduced, depending on the quantity of data stored in the database objects. Addi-tion and deletion of containers in SMS is only possible during a redirectedrestore.

With DMS, the storage allocation within the table space containers is managedby DB2. The containers are either pre-allocated files or raw devices. I/O to thesepre-allocated containers is handled mainly by the database, with little or no OSoverhead. The OS is only involved when pre-allocated file containers are ex-tended or reduced. Also, addition and deletion of containers is possible online viaDDL statements.

To simplify the administration of the table spaces, all table space containersshould be spread as widely as possible on all disk spindles. Although an

46

CHAPTER 3: Storage Management

elaborately designed layout might briefly provide a slight performance benefit (ofperhaps five percent), this simpler approach will provide a more consistent I/Opattern over time. It will also be less vulnerable to additions of new SAP mod-ules, or changes in function and workload. DB2 has also introduced a featurecalled Automatic Storage, in which the database is given a pool of storage (gener-ally two or more file systems), from which table space containers will be allo-cated. Automatic Storage is fundamentally a combination of DMS table spaces(used for the System Catalog and User table spaces) and SMS table spaces (usedfor Temporary table spaces).

In the DBA Cockpit, SAP has not only made the monitoring of database perfor-mance metrics available, as described in Chapter 1, but it has also made themaintenance of table spaces, tables, and indexes available in the SPACES section.

Automatic StorageAutomatic Storage is the default storage layout when installing DB2 with SAPNetWeaver 7.0 and higher. During installation, SAPinst will use sapdata1 throughsapdata4 as storage paths. Depending on the storage subsystem and the numberof LUNs/file systems available, additional storage paths can be added at thattime. Administrators can view the DB2 storage paths from the DBA Cockpit, asshown in Figure 3.1.

Once the database has been created, additional storage paths can be added, if theoriginal file systems containing the table spaces are getting full. Adding new stor-age paths at this time will create a new stripe set of storage for all table spaces.

A new stripe set will not cause a rebalancing of data from the older set of con-tainers into the new storage. The containers in the previous stripe set will befilled before the new stripe set begins to be used. Therefore, to provide equiva-lent performance, ensure that the I/O capacity of each stripe set is the same. Thisrequires a similar number of disk spindles in each stripe set. The simplest way toachieve this is to always keep everything the same. Each time storage is extendedby adding new automatic storage paths, add the same number of sapdata file sys-tems, always using identical LUNs from the storage system.

47


To add new storage paths, just click and enter the new file systems in thedialog shown in Figure 3.2. The new storage locations must exist and be accessi-ble by the database. The bottom of the panel will display the DDL for the ALTER

DATABASE statement, as confirmation of the changes made.

48


Figure 3.1: Automatic Storage storage paths can be managed from within SAP.

Figure 3.2: Click the Add button to add a new storage path.

Table SpacesTable spaces in SAP can either be of Automatic Storage or DMS/SMS type. Bydefault, SAP NetWeaver 7.0 or higher will create the system catalog table spaceand all data table spaces using Automatic Storage, and the temporary table spacesusing SMS. DMS/SMS table spaces can still be created for user data, even if thedatabase uses Automatic Storage.

As shown in Figure 3.3, the Tablespace screen displays the table spaces accord-ing to their type, in either the Automatic Storage tab or DMS/SMS tab.

Detailed data about both the logical and physical storage consumption for eachtable space is displayed in the following columns:

• Contents—The Contents column shows whether the table space wascreated as a Regular, Large, System Temporary, or User Temporary tablespace:

49


Figure 3.3: Table spaces are arranged according to type.

� Regular table spaces are the default for SMS, but they can also be usedfor DMS. They have smaller limits for maximum size and slots (rowsper page) than Large table spaces, and cannot contain LONG/LOBdata.

� Large table spaces are the default for DMS table spaces. They are onlyallowed for DMS. They can contain both user data and LONG/LOBdata.

� System Temporary table spaces store the derived temporary tablesused by DB2 for sorts or joins that are too large to perform in mainmemory.

� User Temporary table spaces store declared global temporary tables,which are used by SAP NetWeaver BW to improve reportingperformance.

• TS State—The state of a table space is usually Normal, but it could be insome other state, such as Quiesce, Backup, or Rollforward.

• KB Total—This is the allocated size of the table space, in kilobytes.

• Page Size—The page size for table spaces can be allocated in 4KB, 8KB,16KB, and 32KB sizes.

• No. containers—This is the number of containers that have been allocatedfor the table space.

• KB Free—This represents the amount of space in the table space that wasallocated, but does not contain any data pages.

• High-Water Mark—For DMS, this represents the current size asrepresented by the page number of the first free extent following the lastallocated extent of a table space.

• Percent Used—This represents the total amount of space consumed up tothe high-water mark, in relation to the total allocated table space size.

50


• Pending Free Pages—This is the number of pages in a table space thatwould become free if all pending transactions were committed or rolledback, and new space were requested for an object.

Maintenance of table spaces can be performed by selecting one of the threechoices shown in Figure 3.4: Change, Add, or Delete. Changing an existing tablespace should be done if any permitted technical setting needs to be modified(such as autoresize or prefetch size). Adding a new table space to DB2 can bedone here. It should be followed by the addition of this new table space to a SAPdata class in Configuration� Data Class. This will ensure consistency betweenthe DB2 table spaces and the SAP DDIC. Deletion of a table space will be re-flected at both the database level and at the SAP data dictionary.

Adding a new table space in Automatic Storage requires the DBA to navigateand modify three tabs. However, the DBA must first provide a new table spacename, beginning with Z or Y, for user customized objects.

The Technical Settings TabNotice in Figure 3.5 that AutoStorage is automatically selected if you create tablespaces from within the Automatic Storage tab. Next, you select the table spacecontent type (Regular, Large, System Temporary, or User Temporary), as de-scribed in the previous section of this chapter.

51


Figure 3.4: Table space maintenancecan be performed directly from withinSAP.

The settings in the Size of I/O Units area of Figure 3.5 will influence how DB2will store the data on disk and access it. The SAP default is 16KB pages, twopages per extent and prefetch size of automatic. The automatic value in thePrefetch Size is a computed value based on the number of containers, the numberof disk spindles, and the extent size. The formula used for this calculation is asfollows:

Prefetch size =(number of containers) *(number of physical disks per container) *(extent size)

52


Figure 3.5: Specify the technical settings when creating new table spaces.

Disk Performance values are predefined, using default values. A different bufferpool could also be assigned to this new table space, although you should maintainonly one buffer pool if all table spaces are of the same page size. DB2 requiresthat there be at least one buffer pool of the corresponding page size for each pagesize used by table spaces.

The Storage Parameters TabThe Storage Parameters tab, shown in Figure 3.6, is used to determine the InitialAllocated Size of the table space, the incremental growth when the table spaceencounters a “table space full” condition (in either kilobytes or percentage), andif there is a maximum size to which the table space can extend. If no maximumsize is specified, the table space will grow until it either reaches the maximum ta-ble space size or consumes all the storage available in the file system. With thedefault 16KB page size, the maximum table space size is 8TB in DB2 9 and 9.5,and 32TB in DB2 9.7.

53


Figure 3.6: Define the storage parameters for new table spaces.

The Containers TabIn Automatic Storage, the database determines the number of containers based onthe number of storage paths assigned. Therefore, adding containers is not permit-ted in Automatic Storage table spaces, as you can see in Figure 3.7.

DMS/SMS Table SpacesThe DMS/SMS tab of the Tablespaces screen is shown in Figure 3.8. As you cansee, the information displayed is very similar to that of the Automatic Storage tab.

54


Figure 3.7: DB2 defines the containers itself for Automatic Storage table spaces.

Figure 3.8: The table spaces for DMS/SMS are listed here.

When adding a new table space under DMS/SMS, the only difference in the Tech-nical Settings is that AutoStorage is not the default, as you can see in Figure 3.9.

In the Containers tab for DMS/SMS, shown in Figure 3.10, the container infor-mation is now required. For DMS containers, you must specify a full path andfile name for each container. For SMS, specify a directory for each container.

55


Figure 3.9: Add a table space in the Technical Settings tab.

Figure 3.10: Container definitions are required for DMS and SMS table spaces.

ContainersTo view all the related containers for the table spaces, select the Containers op-tion. The screen shown in Figure 3.11 will be displayed.

The Containers screen displays storage parameters and statistics in the followingcolumns:

• Stripe Set—The stripe set to which containers belong determines the set ofcontainers across which DB2 will evenly distribute the data. In AutomaticStorage, when additional storage pools are added through “ALTER

DATABASE…ADD STORAGE ON…,” or via the DBA Cockpit, a new stripeset is automatically created. In DMS table spaces, “ALTER TABLE

SPACE…BEGIN NEW STRIPE SET…” will create a new stripe set.

When adding storage to the database, it is always recommended to eitherextend all containers in the current stripe set by the same amount, or createa new stripe set. This keeps the containers balanced and avoids the datamovement and I/O caused by rebalancing.

56


Figure 3.11: The Containers screen displays the containers for all table spaces.

• Container Name—This contains the full path and file name of thecontainer for DMS, or a full directory path name for SMS.

• KB Total—This is the total allocated size, in kilobytes.

• Pages Total—This is the number of allocated pages. The size reported inthe previous column depends on the table space page size and can befound in the table space technical settings.

• Accessible—If the table space is in a Normal state, all containers should beaccessible.

• FS ID/FS Free Size—These two columns relate to the file system onwhich the container resides. If Auto Resize is enabled for the table spacesoccupying the file system, ensure that there is enough space in the filesystem for the table spaces to grow.

Tables and IndexesAn SAP ERP 6.0 system contains over 50,000 tables. You can display all thesetables in the Tables and Indexes section, or you can limit what appears. Whenthis section is first selected, the pop-up filter shown in Figure 3.12 is displayed.You can use this filter to narrow the choices of which tables you would like tosee, choosing from the following criteria:

• A certain table space

• A specific table, or table names that match a pattern

• Tables greater than or equal to a given size

• Flagged tables, which are tables or indexes that have exceed the thresholdfor reorganization

• Large RIDs, which refers to displaying tables in large table spaces thathave not yet been enabled for large RIDs

• Tables that have a status of Not Available

• Tables that have a status of Reorg Pending

57


• Tables that have Type-1 indexes, which were used in DB2 v7 and older,before Type-2 indexes were introduced to improve concurrency

In the Table and Indexes screen, tables that meet the criteria in the filter are dis-played. The tables displayed here are also dependent on a set of DB6 tables thatare populated when the REORGCHK FOR ALL TABLES job is run in the DBAPlanning Calendar. (Select Jobs� DBA Planning Calendar.) If this job hasnever been run, it might be possible that no tables are displayed.

The following columns are represented in the screen, which is shown in Figure3.13:

• Schema—This is the schema of the tables.

• Table Name—This is the name of tables that qualified.

58


Figure 3.12: Selection criteria can filter the tables dis-played.

• F1 REORGCHK formula—This value represents the overflow rows, as apercentage of total rows in the table.

• F2 REORGCHK formula—This value represents the table size divided byallocated space, as a percentage.

• F3 REORGCHK formula—This value represents full pages divided byallocated pages, as a percentage.

• Table Flagged—If this is flagged, the table needs to be reorganized.

• Index Flagged—If this is flagged, the indexes on this table need to bereorganized.

• Size—This is the table size, in kilobytes.

• REORG Check Date—This is the date when REORGCHK was last runagainst the table, or when RUNSTATS was executed from dmdb6srp.

• REORG Check Time—This is the time when REORGCHK was last runagainst the table or when RUNSTATS was executed from dmdb6srp.

59


Figure 3.13: The Tables and Indexes dialog displays the storage characteristics of the indi-vidual database tables.

In older versions of SAP NetWeaver, you can run REORGHK from this screen byclicking , which will be located on the Application menu bar, near thetop of the screen. This opens a window, shown in Figure 3.14, to allow adminis-trators to run a REORGHK on stale tables. New versions of SAP NetWeaver 7.0 nolonger have a REORGHK button. Instead, a REORGHK is executed every time thetable is loaded in Single Table Analysis.

Single Table AnalysisHave you ever wanted to know all the details related to a table? In the Single Ta-ble Analysis screen, you can see all the technical information and statistical dataof both the table and related indexes, and have the ability to run maintenanceagainst it (e.g., RUNSTATS, REORGS, and Compression). You can also get to thisscreen from Space� Table and Indexes, by selecting a table.

60


Figure 3.14: You can run REORGCHK from theApplication menu bar.

The Table TabThe table’s information is categorized into tabs for easy viewing of related data.The Table tab is shown in Figure 3.15. The information in the REORG Check Sta-tistics area of the Table tab is as follows:

• Last REORG Check—This is the date and time REORGCHK was last run.

• Total Table Size—This value represents the size of regular and long datain the table, in kilobytes.

• Total Index Size—This value represents the size of all indexes for thetable, in kilobytes.

• Free Space Reserved—This is the percentage of free space in the table’sallocated pages.

• F1 Overflow Rows—This is the percentage of overflow rows.

• F2 Table Size/Allocated Space—This is the percentage of generalfragmentation in the table.

• F3 Full Pages/Allocated Pages—This is the percentage of full pagesfragmentation.

• REORG Pending—This indicates if REORG is pending.

• Last REORG of Table—This is when REORG was last run.

• Runtime of Last REORG—This is the elapsed time of the last REORG.

The System Catalog area of the Table tab contains these values:

• Last Runstats—This indicates when RUNSTATS was last run against table.

• Tablespace—This is the table space to which the table belongs.

• Cardinality—This is the number of rows in the table.

• Overflow Records—This is the number of rows that span two or morepages.

• No. of Pages with Data—This value represents pages that contain table data.

61


• Total Number of Pages—This is the total number of pages consumed bytable.

• Value Compression—If this is flagged, column-value compression is used.

• Row Compression—If this is flagged, row compression is used.

• VOLATILE—If a table is marked as volatile, RUNSTATS is never runagainst it, as the cardinality of the table changes constantly. VBDATA isan example of a volatile table.

• Pooled, Cluster or Import/Export Table—This flag indicates whether thetable is defined as a pooled table, a cluster, or an import/export table in theABAP dictionary (e.g., CDCLS).

62


Figure 3.15: Storage details for individual tables are available in Single Table Analysis.

The Indexes TabThe Indexes tab, shown in Figure 3.16, displays the statistical information for in-dexes. This information is similar to the table content, except that the REORGCHK

formulas are used to determine the cluster ratio and the index space fragmenta-tion, as follows:

• F7 Ratio of Deleted Index Entries—With Type-2 indexes, it is possiblethat RID entries in the index are pseudo-deleted. (Keys have been markedas deleted when the row is deleted or updated.) This value is the number ofpseudo-deleted RIDs on non-pseudo-empty pages.

• F8 Ratio of Deleted Index Leafs—This is the number of pseudo-empty leafpages, over the number of leaf pages.

The System Catalog area of the Indexes tab contains the following statistics:

• Number of Leaves—This number indicates the leaf pages in the indexB*Tree.

• Number of Levels—This is the maximum number of pages traversed fromthe index root page to a leaf page.

• Sequential Pages—This is the number of index leaves physically locatedon the hard disk sorted by index without large intervals between them.

• Density—This indicates the relative density of the sequential pages, as aproportion of the total number of index pages.

• First Key Cardinality—This is the number of unique values in the firstcolumn of the index.

• First 2 Key Cardinality— This is the number of unique values in the firsttwo columns of the index.

• First 3 Key Cardinality— This is the number of unique values in the firstthree columns of the index.

• First 4 Key Cardinality— This is the number of unique values in the firstfour columns of the index.

• Full Key Cardinality— This is the number of unique values in all columnsof the index.

63


The Table Structures TabThe Table Structures tab, shown in Figure 3.17, holds the table columns’ defini-tions. Note that the column data type is based on DB2’s definition, not the ABAPcolumn data type.

64


Figure 3.16: Index storage statistics are also available in Single Table Analysis.

Figure 3.17: The Table Structure tab displays the columns and their data types.

The RUNSTATS Control TabThe RUNSTATS Control tab is divided into two sections. The left side of the tabcontrols the scheduling and execution of statistics collection. The right side indi-cates the statistics profile (the type of statistics collected) for the table.

The data in the left side depends on the configuration of AutoRunstats. WhenAutoRunstats is enabled (which is the default for SAP NetWeaver 7.0 installa-tions), the screen appears as shown in Figure 3.18. The Statistics Attributes areaof the screen contains the following:

• Not VOLATILE (AutoRUNSTATS Included)—This indicates that the tableis eligible for AutoRunstats.

• VOLATILE (AutoRUNSTATS Excluded)—The table is volatile, so it is noteligible for AutoRunstats.

If AutoRunstats is disabled, a Scheduling section appears in the tab along with aStatistics Attributes section. The Scheduling section provides the followinginformation:

• Automatically—Statistics are collected by CCMS jobs scheduled from theDBA Planning Calendar.

• On User Request—CCMS does not process this table. Statistics must becollected manually by the user.

• Statistics Is Out-of-Date—Statistics are stale, and RUNSTATS isrecommended.

• Deviation—This value is the difference between the cardinality statisticsand the estimated cardinality based on insert and delete activities.

• Collect Data for Application Monitor—The table is monitored by theApplication Monitor (ST07).

65


With AutoRunstats disabled, the Statistics Attributes are as follows:

• Statistics—Statistics are collected for this table. If the table is currentlymarked as volatile, it will be changed to not volatile as soon as statisticsare collected for the first time.

• No Statistics and Volatile—The table is marked as volatile in the systemcatalog, and no statistics will be collected.

The RUNSTATS profile for the table is displayed in the right side of the screen.This displays the type and detail of statistics collected on the table. The TableAnalysis Method shows the options that RUNSTATS will use to collect statisticsfor the table. The Index Analysis Method shows the options that RUNSTATS willuse to collect statistics for the indexes.

66


Figure 3.18: The RUNSTATS Control tab shows how DB2 collects statistics forthis table.

The Index Structures TabThe Index Structures tab, shown in Figure 3.19, lists the Index columns. If the ta-ble contains more than one index, use the navigation buttons to pro-ceed to the next index.

The RUNSTATS Profile TabRUNSTATS can be executed with a previously stored statistics profile to gatherstatistics for a table or a statistics view. This profile must have previously beencreated with the SET PROFILE option of the RUNSTATS command. If such a profileexists, it will be displayed in this tab. Click the RUNSTATS with Profile button atthe bottom of this screen to execute RUNSTATS with this profile.

The Table Status TabThe Table Status tab, shown in Figure 3.20, holds all the size and technical infor-mation of the table. The Physical Size and Logical Size sections break down thespace consumed physically and logically by the different object types of the table.

The following key pieces of information are shown within the Availability andOther Technical Information section:

67


Figure 3.19: The Index Structures tab displays the database data type and size of the col-umns in each index on this table.

• Inplace REORG Status—If running an online, in-place REORG, the statuscould be one of the following: ABORTED, EXECUTING, NULL (no REORG iscurrently running), or PAUSED.

• Large RIDs—Is the table using large RIDs? If the value is PENDING, thetable supports large RIDs (that is, the table is in a large table space), but atleast one of the indexes for the table has not yet been reorganized orrebuilt. Therefore, that index is still using smaller, 4-byte RIDs. It must bereorganized to convert it to the larger, 6-byte RIDs.

• Large Slots—Does the table support more then 255 rows per page? If thevalue is PENDING, the table supports large slots (that is, the table is in alarge table space), but there has not yet been an offline table reorganizationor a table truncation operation. Therefore, the table is still using amaximum of 255 rows per page.

68


Figure 3.20: The table size and status are available in the Table Status tab.

The Compression Status TabDB2 introduced table data compression in DB2 9.1, and further enhanced it withAutomatic Data Compression (ADC) in DB2 9.5. Index and Temporary tablecompression are not supported as of DB2 9.5. ADC enables DB2 to automati-cally compress data that is loaded into a table created with the COMPRESS YES op-tion, without running a REORG to build the compression dictionary.

The Compression Status tab is shown in Figure 3.21. If compression has been en-abled on the table, the Compression Details area of the tab displays the compres-sion statistics. Otherwise, if a compression check has been executed on the table,the Compression Check Results can be used to evaluate the potential benefits ofcompressing that table. The following information is displayed in this sectionwhen the table is enabled for compression, and compression has already been ap-plied to the data rows of the table:

• Current Dictionary Size—This is the compression dictionary size, in bytes.The compression dictionary has a maximum of 150 KB, and can store upto 4,096 compression symbols per table object.

• Approximate Percentage of Pages saved—This is the percentage of datapages saved, by compression.

The Compression Check Results section shows the estimation of what can be ex-pected if compression were enabled on the data rows of the table. It contains thefollowing values:

• Estimated Saved Pages—This is an estimate of the number of pages thatwill be saved after compression, as a percentage.

• Estimated Saved Bytes—Commonly referred to as the compression ratio,this is the estimated bytes that will be saved after compression, as apercentage.

• Rows too Small—This is the number of rows that were too small to beused for compression calculations.

69


The Application menu bar, shown in Figure 3.22, provides options to runRUNSTATS, REORG, and Compression on the table. Select one of the buttons tostart the action.

When RUNSTATS is select to be run in the background, the dialog menu shown inFigure 3.23 is displayed, with choices on how statistics will be collected for boththe table and index. Once the statistics collection method has been chosen, thejob could be run once, or repeated on a schedule from the Recurrence tab.

70


Figure 3.21: DB2 Deep Compression statistics are shown in the Compression Status tab.

Figure 3.22: Some database utilities can be run from the Single Table Analysis Applicationmenu bar.

To check if a table is a good candidate for compression, click toschedule a background job. The resulting estimate will be displayed in the Com-pression Check Results section of the Compression Status tab screen. This actionwill not create the compression dictionary, turn on the COMPRESS flag, or com-press any rows.

To enable Compression, select . The dialog box in Figure 3.24 willprompt you for the method of compression to use. The Status section indicates ifthe COMPRESS YES flag was set on the table, either through CREATE TABLE orALTER TABLE, and if a compression dictionary pre-existed. There are then twooptions for enabling compression:

• Enable Compression—This will build the compression dictionary, butleave all existing data in the table uncompressed. New or changed datawill be eligible for compression.

71


Figure 3.23: Set the RUNSTATS parameters when schedulingbackground statistics collection.

• Enable Compression and Run REORG—This will build the compressiondictionary, run an offline REORG against the table, and compress allexisting rows in the table. All new rows added to the table are eligible fordata compression.

Virtual TablesVirtual tables were introduced by SAP to save disk storage and help improve theperformance of many utilities, such as Automatic RUNSTATS and AutomaticREORG. The concept of virtual tables is simple. Do not materialize (create) anempty table in the database. Instead, just logically define it in the SAP DDIC.When the first row is inserted into a virtual table, the SAP Database SupportLayer (DBSL) determines that the table does not yet exist in the database. It is-sues the CREATE TABLE statement to materialize the table before inserting thatfirst row.

SAP systems contain thousands of empty tables. Each empty table may consumeas many as 11 extents (22 pages or 352K, with the default 16K page size and ex-tent size of 2). These extents are consumed by the following:

72


Figure 3.24: Select whether to compress just new rows, or bothnew and existing rows.

• One Extent Map Page (EMP) extent

• One data extent

• Two extents for the index object

• One page for each index

• Two extents for a LONG field object

• Four extents for a LOB object

The first screen in the Virtual Table tab, shown in Figure 3.25, lists all of the vir-tual tables in the system. To materialize a virtual table manually, select it andclick the Materialize button.

73


Figure 3.25: The Virtual Tables tab contains the list of virtual tables.

The second tab in the Virtual Table screen, shown in Figure 3.26, lists all theempty tables that are eligible to be converted to virtual tables. If the ConvertEmpty Tables button was selected, all eligible tables will be dropped from the da-tabase and re-created as virtual tables in a background job. Eligible tables matchthe following criteria:

• Empty

• Non-volatile

• Does not have a partitioning key defined

• Non-MDC

74


Figure 3.26: Empty tables that can be virtualized are listed in the Candidates forVirtualization tab.

Historical AnalysisThe History Overview screen provides a general overview of the size and quan-tity of table spaces, tables, and indexes in the database. The Database andTablespaces tab of the screen is shown in Figure 3.27.

This tab provides the following statistics:

• Last Analysis—This date and time indicates when the last analysis was runto collect the history information of the database objects.

• Total Number—This is the number of table spaces in the database.

75


Figure 3.27: A database size overview is provided in the Database and Tablespacestab of the History Overview.

• Total Size—This is the total size of all table spaces.

• Free Space—This is the amount of free space (in kilobytes) in all the tablespaces.

• Used Space—This is the amount of space used, as a percentage of total space.

• Minimum Free Space in a Tablespace—This is the free space of the tablespace with the lowest amount of free space (in kilobytes). This informationis of little value if the table spaces are of Automatic Storage Table Spaceor have RESIZE enabled, as they will be resized when they are filled.

• Maximum Used Space in a Tablespace—This is the percentage of usedspace of the table space with the most amount of data.

Database Partitions—This value provides the number of partitions in amulti-partitioned SAP NetWeaver BW database. The Tables and Indexes tab ofthe History screen, shown in Figure 3.28, provides an overview of the quantityand space consumed by the database’s tables and indexes.

76


Figure 3.28: The Tables and Indexes tab displays the size of the tables and indexes.

The Database and Table SpacesThe History—Database and Tablespaces screen, shown in Figure 3.29, displaysthe change history for the database, tables, and indexes. You can use the informa-tion here to help plan capacity.

Double-clicking a row in the list of tables and indexes shown in Figure 3.30 dis-plays a detailed history that documents the item’s size changes over time.

77


Figure 3.29: The Space tab displays the change history of database and ta-ble space storage consumption..

Figure 3.30: The Tables and Indexes tab displays the historical storage consumption for ta-bles and indexes.

In the example in Figure 3.31, the Delta Tables value for 07/03/2008 was nega-tive, indicating that some tables were deleted from the database. In this case, theywere converted to virtual tables.

Tables and IndexesThis History—Tables and Indexes screen, shown in Figure 3.32, provides accessto the historical data of tables and indexes. Initially, this screen displays all thetables and indexes found in the database with their respective sizes and changes,together with REORGCHK information.

78


Figure 3.31: Historic details of a database’s size changes are available here.

Selecting any object and double-clicking its row provides more historical data forthat object, as shown in Figure 3.33.

79


Figure 3.33: Double-click a table to see its historical size changes.

Figure 3.32: Histiorical size changes for the tables and indexes are displayed here.

SummaryManaging database storage, monitoring database object size, and planning stor-age capacity are all key operations for ensuring the stable, efficient, andcost-effective operation of any SAP system. The SAP DBA Cockpit provideseasy access to many of the most important DB2 features for storage management.Regular maintenance tasks, such as reorganization and statistics collection, are alleasily executed on-demand, scheduled as repeating jobs, or enabled for automaticDB2 maintenance with a couple of mouse clicks. Powerful performance andspace-optimization features, such as compression and virtual tables, are also fullyintegrated by SAP into the DB2 cockpit, making the unique benefits of DB2 easyto implement in an otherwise complex environment.

80


Chapter 4

Job SchedulingFlying on Auto-Pilot

The DBA Planning Calendar saves time and reducesadministrative effort by giving DBAs a simple interface toschedule the most common repeating maintenance jobs,

and an efficient way to create, save, and schedulecomplex database administration tasks.

Automating tasks is one of the easiest ways to reduce workload. SAP onDB2 provides an integrated interface for both job scheduling and monitor-

ing. Administrators can monitor all SAP systems on the central planning calen-dar, or modify recurring database jobs through the DBA Planning Calendar.There is even an interface to create and store custom scripts, and then schedulethose scripts in the calendar.

The Central Calendar

The SAP Central Calendar, shown in Figure 4.1, displays the complete list ofuser-defined database background jobs scheduled on all SAP systems configuredfor central monitoring. It is a read-only, holistic view that provides administratorsa single point from which they can monitor database jobs for remote systems

81

running different versions of SAP, different relational databases, and databasesfor Java stack and non-SAP systems.

When registering a remote system is registered in the DBA Cockpit, you mustclick the Collect Central Planning Calendar Data checkbox to allow SAP toupdate the central calendar with the job status for this system. Then, schedule theCentral Calendar Log Collector job to run every morning on the system normallyused for monitoring. This will collect and consolidate all the remote systems’ cal-endar data on that one SAP system.

The central planning calendar shows a single entry for each system with a jobscheduled for that day, in the format “001 <SID> 001,” where <SID> is the SAPsystem ID. The first number indicates the number of jobs scheduled for that dayfor the given SID. The second number indicates the number of those jobs thathave finished with the same, highest status severity. The severity will be indi-cated with a color code for that cell in the calendar.

82

CHAPTER 4: Job Scheduling

Figure 4.1: The Central Calendar shows all database jobs for all registered SAP systems.

You can easily see which systems and jobs have had warnings or errors. Dou-ble-click any date on the calendar to view the details of all the jobs scheduled onall systems for that date. Double-clicking any specific entry takes you to theDBA Planning Calendar for that date and SAP system. This allows administra-tors to view the detailed job logs, and then modify or re-execute those jobs.

The DBA Planning Calendar

The DBA Planning Calendar, shown in Figure 4.2, is used to automate regularly re-curring database jobs. Any recurring database process can be automated throughthe calendar. However, many of the most common jobs are predefined in an ActionPad within the calendar. Administrators need only drag and drop the jobs from theAction Pad to the calendar to schedule their execution on the SAP system.

When a new SAP system is installed, no recurring jobs are initially scheduled.The administrator must determine the pattern of jobs required for that system.These jobs may, or may not, run in parallel. Therefore, the schedule must takeinto account dependencies between the jobs and their impact to the system. Thereare also a few database-related jobs that run regularly in every SAP system:

• Collection of database performance history—This job runs every twohours, starting at 00:00.

• Monitoring database and database manager configuration parameterchanges—This job runs daily at 08:00, 13:00, and 19:00.

• Collection of table and index space history—This job runs weekly onSunday, at 12:00.

Keep these jobs in mind when planning the DBA background jobs in thecalendar.

83


The DBA Planning Calendar provides a wizard to help with the initial setup ofthe recurring administration tasks on each SAP system. To run the wizard, clickthe Pattern Setup button. This wizard steps through the setup of a backup sched-ule, automatic table REORG, and the scheduling of the REORGCHK for all Tablesjob. For each job, reasonable default times are provided, but these can bechanged as desired. The remaining jobs can either be scheduled from the list ofcommon jobs in the Action Pad next to the calendar, or created and scheduled inthe calendar as a command line processor (CLP) script.

REORGCHK for All TablesThe REORGCHK for all Tables job must be scheduled in all DB2 SAP systems.This job performs much more than just the standard DB2 REORGCHK. It is veryimportant for the proper display of Space data in the cockpit (formerly transac-tion DB02). This job performs the following tasks:

84


Figure 4.2: The DBA Planning Calendar provides scheduling and monitoring of backgrounddatabase jobs.

• Executes the DB2 REORGCHK tool to obtain REORG recommendations fortables and indexes

• Calculates the size of tables and indexes, which is used for creatingincremental space consumption history

• Determines special situations for tables (e.g., REORG_PENDING)

• Can perform compression estimates, starting with SAP BASIS 7.0 SP12

All calculated data is stored in SAP database tables and displayed in the DBACockpit under Space� Tables and Indexes. Therefore, the REORGCHK for allTables job should be scheduled to run weekly, to ensure that accurate data is dis-played in the cockpit. SAP recommends excluding the compression check fromthe recurring job, because a compression check of all (potentially over 50,000)tables can take a long time. If you need a full compression check, schedule itonce during low workload hours, or use the /ISIS/ZCOMP ABAP report, at-tached to SAP Note 980067. (See SAP Note 1268290 for the most recent recom-mendations about the REORGCHK for all Tables job.)

Scheduling BackupsThe calendar’s Action Pad now contains four options for backup:

• Database Backup into TSM—Back up to Tivoli Storage Manager.

• Database Backup to Device—Back up to a file system directory or tapedevice.

• Database Backup with Vendor Library—Back up to a different storagemanager, such as Veritas NetBackup.

• Snapshot Backup—Back up using flash copy and split mirror.

You can schedule full backups, or a combination of delta, incremental, and fullbackups to satisfy your time and recovery requirements. All backups scheduledthrough the DBA Planning Calendar are now done online.

85


Archiving Log Files to a Tape DeviceIf archive logging is configured to a disk location in LOGARCHMETH1, the DB2Tape Manager can be used to move those archived logs to a tape device. The Ar-chive Log Files to Tape job can be scheduled periodically in the DBA PlanningCalendar to perform this task. The default behavior of the Tape Manager is tocopy log files to the specified tape device, and then remove the log files from thefile system specified in the LOGARCHMETH1 database configuration parameter.

Options can be specified in the calendar’s job scheduler to archive each log fileto two different locations on tape (the Double Store option), overwrite expiredtapes, or eject the tape at the end of the operation. You should always keep tworedundant copies of each archive log file. Therefore, either set LOGARCHMETH1

and LOGARCHMETH2 to different file systems, or use the Double Store option ofthe Tape Manager to keep two copies of each log file on tape.

Updating StatisticsBy default, DB2 updates statistics automatically using its Real Time Statistics(DB2 9.5) and Automatic RUNSTATS features. Every two hours, a daemon pro-cess checks tables for change activity and updates the table statistics, if neces-sary. With DB2 9.5 Real Time Statistics, if the optimizer determines thatstatistics are too stale to provide acceptable query performance, it invokes statis-tics collection or estimation during query optimization. This removes almost allneed for administrators to worry at all about table statistics.

By default in SAP, both regular and distribution statistics are collected for all ta-bles, and detailed statistics are collected for all indexes using sampling. This aug-ments the regular table statistics with additional range histogram data for allcolumns of the tables, and collects detailed statistics for the indexes by samplingthe individual index keys in each index. For SAP NetWeaver BW tables, tablestatistics are only collected on key columns. If a different statistics collectionmethod is desired for certain tables, administrators can either update the statisticsprofile using the DB2 RUNSTATS command, or schedule the RUNSTATS andREORGCHK for Single Table job, which allows the RUNSTATS parameters to betailored specifically for that RUNSTATS invocation.

86


Table ReorganizationThere are several jobs and maintenance settings for reorganizing tables. Althoughthere is an Automatic REORG job in the planning calendar, the native DB2 auto-matic REORGis recommended instead for tables smaller than 1GB. This is ex-plained further in Chapter 6. For larger tables, REORG jobs can be run on demand,or scheduled periodically through the calendar.

Since larger tables are excluded from automatic REORG, a REORGCHK must be per-formed on these tables periodically, to determine when a REORG is required. Thiscan be done by scheduling the REORGCHK for All Tables job. This job is also a pre-requisite for the correct functioning of the Space Tables and Indexes dialog screenin the DBA Cockpit (formerly transaction DB02). Therefore, this must be scheduledto occur regularly in every SAP system. You should run it at least once weekly.

The Action Pad then contains three additional table REORG jobs:

• REORG and RUNSTATS for Set of Tables—This job allows the administratorto enter a list of tables to be periodically reorganized. The REORG can bedone in either offline (read-only) or online mode.

• REORG and RUNSTATS of Flagged Tables—This job reads the flagged tabledetails from the REORGCHK for All Tables job, and generates a list of tablesto be reorganized. Since the list of tables is generated when the job isscheduled, this job does not recur; it must be scheduled each time it is to beexecuted. The administrator can select all or part of the list for offline tablereorganization, and specify an optional maximum runtime for this job.

• REORG of Tables in Tablespace(s)—This job allows the administrator toselect one or more table spaces for reorganization. An offline REORG willthen run on all tables in that table space. The administrator can again selecta maximum runtime for this job.

Custom Job ScriptsCustom command line processor (CLP) scripts can be written, saved, and sched-uled for recurring maintenance or administrative tasks not available in the ActionPad. Simply select the CLP Script job from the action pad, and you can write

87


new scripts, load scripts from text files, or select predefined CLP scripts createdfrom the SQL Script Maintenance dialog screen. These custom scripts can thenbe scheduled in the calendar in the same manner as any other job.

It is convenient to create background-job CLP scripts in the SQL Script Mainte-nance screen and save these scripts within SAP. You can then select these scriptsfrom a drop-down list when scheduling recurring CLP script jobs.

All jobs are listed on the DBA Planning Calendar with a color code to specifystatus. Any entry on the calendar can be clicked to display its details. Future jobscan be modified. Completed jobs can only be viewed, and also contain a tab todisplay the Job Log. The Job Log contains the status messages and output pro-duced by the background job. This provides a good first point of problem deter-mination for jobs that do not complete successfully.

The DBA LogThe DBA Log, shown in Figure 4.3, displays a color-coded list of database back-ground jobs run on the current system. It contains the start and end times, the ac-tion performed, and the return code status of the job.

88


Figure 4.3: The DBA Log displays the status of database background jobs.

The display defaults to the list of jobs executed during the current week. Previousweeks can be displayed by double-clicking dates from the calendar. The displaycan also be filtered by severity, by clicking the status icons ( ) in theSummary. This gives administrators a very easy way to view weekly job statusand identify any jobs that did not complete successfully.

Back-end ConfigurationThe Change Back End Configuration screen, shown in Figure 4.4, provides an in-terface to control the execution of the DBA Planning Calendar’s background jobson different SAP systems. For each system, a unique background server, user,and job priority can be configured.

89


Figure 4.4: The Change Back End Configuration dialog configures the server, priority, anduser for executing background database jobs.

SQL Script MaintenanceThe SQL Script Maintenance screen, shown in Figure 4.5, provides a SAP repos-itory for custom-coded DB2 CLP scripts. Administrators can add, modify, or de-lete custom SQL scripts. All saved scripts appear in a list in this screen, fromwhere they can be selected and executed. The user is prompted for the SAP sys-tem on which to run the script, and then the output is displayed back into the SAPGUI screen.

More commonly, the saved SQL scripts can be scheduled from the DBAPlanning Calendar, by selecting the CLP Script job from the Action Pad. Thesaved scripts can be selected from a drop-down list, and then scheduled to recuras required. The status of these jobs is then displayed in the DBA Log. To viewdetailed results of a job, double-click it from the DBA Planning Calendar or fromthe Job Overview (transaction SM37).

90


Figure 4.5: SQL Script Maintenance allows administrators to store frequently run SQLscripts within SAP, so they can be scheduled easily in the DBA Planning Calendar.

SummaryThe DBA Cockpit for DB2 contains all the functionality administrators need toeasily schedule and monitor any type of recurring database task in SAP systems.Predefined jobs and centralized monitoring greatly simplify normal SAP data-base maintenance, and the custom repository provides the flexibility to easily de-fine, maintain, and schedule more complex database maintenance tasks.

91


Chapter 5

Backup and RecoveryReviewing Your Flight Logs

The DBA Cockpit Backup and Recovery option displaysall the information that a DBA needs to verify the

successful operation of the database backupand log archival processes.

SAP applications store their data in the underlying database, in this case DB2.Objects like application and technology tables, ABAP programs, and user

data (customizations and transactional data) are all stored in DB2 database ob-jects. Therefore, administrators need to protect the database, so it can be recov-ered in case of a problem (such as a user or application error) or a majorcatastrophe (such as a disk crash).

Two components work in conjunction to protect the database: database backupsand transaction log files. Backups can recover the database up to the point when thebackup was taken. Log files can recover the remaining transactions that were com-mitted after the backup. Transaction log files work in a circular mode by default,meaning that they are not archived; old transactions are overwritten by new ones.

The first step to enable the necessary protection to the data is to enable archivallogging for the SAP database. To do that, the DBA needs to configure the

92

LOGARCHMETH1, and optionally, LOGARCHMETH2 database configuration param-eters and take a full offline backup of the database. When archival logging is en-abled for the database, the transaction logs are automatically archived to themethod(s) specified in these parameters, so no manual intervention is necessary.

The second step to protect the database is to take backups regularly, so that fewertransaction log files are applied to recover the database to the latest consistentpoint in time. Backing up the database is a recurring task. The best way to pro-gram these backups is to schedule jobs in the DBA Cockpit.

Finally, it is also crucial that the DBA validates the backup procedure by check-ing the message logs, and most importantly, through programmed restores on atest system. We recommend a restore test once every three months.

The Backup StrategyThe DBA needs to define a backup strategy for the SAP database based on differ-ent options and considerations:

• Frequent database backups—More backup images means less dependencyon transaction logs for recovery. However, backups consume resourceslike memory and I/O, so they can affect the performance of the database.Using the backup utility in throttled mode is an option to alleviate theperformance impact.

• Few database backups—With few database backups, the DBA relies moreon the transaction logs for a possible database recovery. The problem withthis approach is that there could be many transaction logs to apply, sorecovery could take longer.

• Use of full and incremental backups—The combination of full andincremental backups can be used in the backup strategy. Incrementalbackups tend to be faster and smaller than full backups, but do not containall the data in one single backup image to restore the database completely.

93

CHAPTER 5: Backup and Recovery

Another fact worth noting is that the backup utility spawns multiple DB2 agents,to increase parallelism during the backup procedure. DB2 uses at most one agentper table space. In some cases, therefore, you might consider separating some ta-bles (usually the largest ones) in their own table spaces, to increase parallelismduring the backup of the database.

Utility ThrottlingAs a DB2 administrator, you must perform some regular maintenance tasks tokeep the database running at optimal performance while protecting its data. Manyof these maintenance tasks are performed through DB2 utilities (in both onlineand offline mode), such as these:

• BACKUP, a data backup utility covered in this section

• REORG, which defragments tables and indexes

• RUNSTATS, for statistics collection

• REBALANCE, which rebalances extents among all containers of a tablespace

The fact that these utilities must execute regularly causes a dilemma for theDBA, since they consume system resources and can affect the performance of thedatabase. You can opt to run these utilities in an offline maintenance window, butin a 24x7 world, such windows are getting smaller or are even non-existent.Therefore, in most cases, these utilities must execute online with user transac-tions. Your challenge is to minimize their impact on the system.

DB2 provides a feature called adaptive utility throttling, which allows mainte-nance utilities to run concurrently with other user transactions, while keepingtheir system resource consumption in controlled limits. Before running utilities inthrottled mode, the DBA has to enable a database manager configuration parame-ter, called UTIL_IMPACT_LIM. This parameter dictates the overall limit at the in-stance level that all utilities together can affect. Values for this parameter rangefrom one to 100, and the unit of measure is a percentage of allowable impact onworkload within this DB2 instance. For example, setting this parameter to 100means that all utilities run in unthrottled mode.

94


Once this instance-wide limit is specified, you can run utilities in throttled modewhen they are started or after they have started running. To run in throttled mode,a utility must also be invoked with a non-zero priority. For example, to run thebackup utility in throttled mode, specify the following option when launching theBACKUP command:

backup database <SID> util_impact_priority 60

The UTIL_IMPACT_PRIORITY option accepts values between one and 100, withone representing the lowest priority, and 100 the highest. If theUTIL_IMPACT_PRIORITY keyword is specified with no priority, the backup willrun with the default priority of 50. If UTIL_IMPACT_PRIORITY is not specified, thebackup will run in unthrottled mode.

If there were another utility running at the same time in throttled mode (for ex-ample, a RUNSTATS with priority 50), both utilities combined should affect thesystem at a maximum limit of UTIL_IMPACT_LIM. The utility with higher prioritywould get more of the available resources.

The DBA also has the option to specify the backup priority directly on the DBACockpit, when the backup job is scheduled through the DBA Planning Calendar(described in the following section). Again, this will only have an effect if theUTIL_IMPACT_LIM (impact policy) has been set to a value other than 100. (SAP’sstandard configuration has this parameter set at ten percent.)

Scheduling Backups in the DBA CockpitAs described in Chapter 4, database tasks are scheduled through the DBAPlanning Calendar. Four backup options are offered in the Action Pad:

• Database Backup into TSM—Back up to Tivoli Storage Manager.

• Database Backup to Device—Back up to a file system directory or tapedevice.

• Database Backup with Vendor Library—Back up to a different storagemanager, such as Veritas NetBackup.

95


• Snapshot Backup—Back up using storage copy technology, such as FlashCopy and Split Mirror.

When one of these backup actions is dropped into the calendar, a new windowpops up, Schedule a New Action, shown in Figure 5.1. Backup options are speci-fied in this window.

In the Action Description area of this window, the DBA can redefine the action,date, and time. In the Action Parameters tab, you can choose different options forthe backup, such as these for Backup Mode:

96


Figure 5.1: Schedule a new backup action here.

• Online—The database is available for other applications, but the backupimage is not consistent. Log files must be applied to bring the database to anormal state, in case of recovery.

• Online Include Logs—The database is available for other applications, andthe backup image produced contains all the information necessary to bringthe database to a consistent state, should a recovery be necessary. There isno dependency on separate log files to bring the database to a normal state.

Note that online backups are only possible when log archival mode is enabled.(Archive logging ensures that log files are saved when they fill up, and are notreused.)

There are three options on the tab for Backup Type:

• Full—The entire database is backed up.

• Incremental—Only changes since the last full backup are copied.

• Incremental Delta—Only changes since the last successful backup(whether full or not) are copied.

The TRACKMOD database parameter needs to be set to YES to use the options forincremental backups.

Clicking the Compress checkbox in the tab means the backup image is created incompressed format. There are also several optimization parameters on the tab:

• Number of Buffers—This is the number of backup buffers used for thebackup operation.

• Buffer Size—This is the size of each backup buffer.

• Parallelism—This is the number of table spaces that can be read inparallel by the backup utility.

97


These parameters are not mandatory. If not specified, DB2 will define optimalvalues for the parameters without explicit values. The remaining two parametersin the tab are as follows:

• Priority—The backup will run in throttled mode, with the priorityspecified, where one represents the lowest priority, and 100 represents thehighest. Throttling allows the administrator to regulate the performanceimpact of the backup operation.

• Device/Directory—This is the device or directory path specified to storethe backup image created.

Once the backup options are specified, add the task to the DBA Planning Calen-dar using the Add button. The backup can be monitored in the Job Log tab,shown in Figure 5.2.

98


Figure 5.2: The Job Log screen can be used to monitor the progress of the backup.

If you have access to a terminal and can log into the machine where the databaseserver resides (as db2<SID> or another user with the necessary authority), you candisplay more details about the backup job using the LIST UTILITIES command.The output of this command, shown in Figure 5.3, includes interesting informa-tion about all utilities that are running at the moment. For backups, some of theinformation presented includes the database name, description, state, throttlingmode, and percentage complete.

With database backups, logs archived, and validation tests, you now provide thenecessary protection to the SAP database. Should a recovery be needed, youwould restore the database using one of the backup images, and then apply thelogs up to the time of interest.

Multi-partition Databases

To handle a multi-partition database, the DBA Cockpit offers the options to backup each partition individually or to back up all of them in one single job. On DB29.5, there is a new feature called single system view, in which a multi-partition

99


Figure 5.3: The LIST UTILITIES command can also be used to monitor the progress of thebackup.

database is managed similarly to a single-partition one, in terms of backups andconfiguration of parameters.

To back up all partitions of a database in a single job, just select the option All inthe Partition field (only available when the database is multi-partition), displayedin the Schedule a New Action window.

Advanced Backup TechnologyToday, SAP databases often grow very large. It is common to see SAP systems inthe order of tens of terabytes. With databases this large, instead of using the regu-lar DB2 backup utility, you might substitute backups taken with storage technol-ogies like Flash Copy. In this case, DB2 provides a means to stop I/O operationson the database, so storage commands can be applied to copy the LUNs used bythe SAP database. For recovery, DB2 provides the db2inidb command.

On DB2 9.5, this type of backup is integrated into the backup utility, so fewerconfigurations are necessary. This backup option is available in the DBAPlanning Calendar (Action Pad) as Snapshot Backup.

The DB2 Recovery History FileEvery DB2 database contains a history file. This file is used to record databaseactivities, such as database and log files backups, database restores, table spacemanagement, table load, and table reorganizations. The contents of this file canbe displayed with the LIST HISTORY command. For example, this is the commandto see information about all backups for a particular database:

list history backup all for db <SID>

The recovery history file can grow very quickly, so DBAs might have to prunesome of the old information. This is done with the command PRUNE HISTORY.

The num_db_backups and rec_his_retentn database parameters can be used tomanage the amount of information kept in the history file. The num_db_backups

100


parameter specifies the number of backups to keep active in the history file. Oncethe number of backups exceeds this value, the oldest backups are marked as ex-pired in the history file. The entries for these expired backups are then deletedfrom the history file when the next backup is performed.

The rec_his_retentn parameter specifies the number of days to keep backup infor-mation in the history file. This configuration parameter should be set to a valuecompatible with the value of num_db_backups. For example, if num_db_backups

is set to a large value, rec_his_retentn should be large enough to support thatnumber of backups. The PRUNE HISTORY <timestamp> command will removebackup information from the history file for backups older than the value of thisparameter. If this value is set to -1, um_db_backups determines the expiration ofhistory file entries.

If the following command is run, the archived log files will also be removedfrom the archive storage location:

PRUNE HISTORY <timestamp> AND DELETE

However, the DB2 backup images still need to be manually deleted after they expire.

With DB2 9.5, DBAs can also set the database configuration parameterauto_del_rec_obj=on, which enables DB2 to automatically do the following oper-ations when either the PRUNE HISTORY AND DELETE or BACKUP commands arerun:

• Delete expired backup images from the file system.

• Delete corresponding expired archived log files from the archive media.

• Prune the expired entries from the history file.

Setting these parameters allows DB2 9.5 administrators to simply schedule nor-mal backups. When those backups complete, DB2 will automatically maintainthe required number of backups, archived logs, and history entries, and automati-cally delete anything that has become expired.

101


The Backup and Recovery Overview ScreenThe Backup and Recovery Overview screen displays information about pastbackups and log archival information. These two pieces of information are sepa-rated by two different tabs: Database Backup and Archived Log Files.

The Database Backup TabThe Database Backup tab, shown in Figure 5.4, contains information about back-ups that were scheduled and have been processed. By default, the DBA Cockpitdisplays backup information from the last 30 days. (This can be changed to seeolder information.) For details, double-click in the backup execution of choice.

The DBA Cockpit also categorizes the backup executions using a color scheme.An execution displayed in green means that it finished successfully. If a backupexecution is red, it was aborted with an error. The DBA can then diagnose thebackup failure using the Diagnostics option of the DBA Cockpit (discussed inChapter 8).

The Archived Log Files TabThe Archived Log Files tab, shown in Figure 5.5, displays information abouttransaction log files that were moved from the active log directory to the archivedestination, such as a different directory or a Storage Manager (TSM, Veritas,Legato, etc). Notice that the DBA Cockpit also displays the log chain in which a

102


Figure 5.4: The execution status of previous database backups can be checked here.

log file belongs. A log chain is a DB2 feature used to control log files that havethe same name but different contents. With this feature, the DBA doesn’t need tomanually control which logs to apply in a recovery scenario. DB2 manages thisautomatically.

Logging ParametersThe Logging Parameters screen shows information about the transaction logfiles. Transaction log files are used to keep track of database transactions. Thesefiles are used in recovery scenarios (crash or roll-forward recovery). The follow-ing recovery scenarios require log files:

• Crash recovery—This is the procedure to recover the database to aconsistent state when the database aborts in an abnormal way. Log filescontaining non-committed transactions, or transactions that have beencommitted but not yet applied on the table spaces, are used in this case.These logs are called active log files.

• Roll-forward recovery—This procedure is used when recovering thedatabase from a backup image and log files. In this scenario, log files thathave been archived are also used.

This screen is divided into multiple tabs: Log Directory, RCHMETH1, and possi-bly ARCHMETH2. (The ARCHMETH2 tab will be displayed when you have enabled

103


Figure 5.5: The log files that have been archived are displayed here.

two methods to archive log files.) The archival methods are controlled by the da-tabase configuration parameters LOGARCHMETH1 and LOGARCHMETH2.

The Log DirectoryThe information displayed in the Log Directories tab, shown in Figure 5.6, re-lates to active and online archive log files. Some of the data provided here in-cludes the directory name, the number of files and directories, the first active logfile (for crash-recovery purposes), the size of the log files, and the number of pri-mary and secondary logs.

From here, you can also monitor the space used and available in the file system.This monitoring is necessary to avoid “log full” error messages, when there is nomore space available for new log files. You can set the blk_log_dsk_ful databaseconfiguration parameter, so that the DB2 database manager will repeatedly at-tempt to create the new log file until the file is successfully created, instead of re-turning “disk full” errors.

For performance reasons, the log directory should also be mounted on separatedisks, preferably on RAID 10 LUNs.

104


Figure 5.6: The Log Directory tab displays information about log files, as well as log spaceusage.

The ARCHMETH1 TabThe ARCHMETH1 tab, shown in Figure 5.7, displays information about the archi-val method specified in the database configuration (parameter LOGARCHMETH1).This parameter specifies the location of the archived transaction logs.LOGARCHOPT1 specifies log archive options, which are used when the log filesare archived to Tivoli Storage Manager.

SummaryDatabase backups and log file management are essential activities to protect theSAP system against unplanned situations. Planned situations, such as systemcloning, are also related to backups and log files activities. Such activities can beeasily scheduled and monitored through the DBA Cockpit, as described in thischapter.

105


Figure 5.7: The ARCHMETH1 tab displays information about the logs saved by the log ar-chive method specified.

Chapter 6

ConfigurationOptimize Your Flight Patterns

The default DB2 configuration settings are optimized fornormal SAP workloads and provide the best possible

performance “out of the box.” The DBA Cockpit providesDB2 DBAs with an SAP interface to further tune their

configurations for the unique workloads on their SAP systems.

Database configuration is one of the areas that greatly influences databaseperformance. Therefore, it is a major area of database performance tuning.

A well-configured database environment can ensure the database manager runssmoothly in a multi-user system and responds to each user application quickly byusing the resource available on the database server, effectively and efficiently.

With DB2 LUW, four areas of a database environment can be configured:

1. Operating system environment variables

2. DB2 profile registry variables

3. Database manager configuration parameters

4. Database configuration parameters

All of the variables and configuration parameters in these areas have default val-ues supplied by DB2. However, the DB2 default values will usually not meet the

106

performance required by SAP systems. Therefore, SAP provides its own set ofdefault or recommended values for these variables and configuration parameters.SAP default values can be obtained from the following SAP notes, one for eachsupported DB2 version, respectively:

• 584952, “DB6: DB2 UDB ESE Version 8 Standard Parameter Settings”

• 899322, “DB6: DB2 9 Standard Parameter Settings”

• 1086130, “DB6: DB2 9.5 Standard Parameter Settings”

In these notes, some parameter values are recommended by SAP and should notbe changed. Other parameter values, though, are initial values that should be ad-justed according to the particular system workload, as well as the hardware re-source available. These SAP default values will also be set automatically duringthe SAP installation.

On one hand, a large number of variables and configuration parameters can betuned. This book only discusses the most important ones. Configuration parame-ters also vary in different DB2 version. Our discussion is based on the latest DB2version, 9.5. On the other hand, many configuration parameters can be simply setto AUTOMATIC so that DB2 can automatically set the parameter values, or tunethem dynamically based on the system workload and resource.

Autonomic computing is one of the strategic directions of DB2 product. The ulti-mate goal for DB2 is to become self-configuring, self-healing, self-optimizing,and self-protecting. Hence, DB2 becomes a zero-administration database. Bysensing and responding to situations that occur, autonomic computing shifts theburden of managing a database system from database administrators to DB2technology. This greatly reduces the total cost of ownership (TCO).

In addition to these DB2 variables and configuration parameters, the DBA Cock-pit also provides maintenance tool for other areas of database and system config-uration. All of these tools are organized in the following sections under theConfiguration menu:

107

CHAPTER 6: Configuration

The Overview ScreenChoose Configuration� Overview, and you will be able to view the generalinformation about the database and the operating system, as shown in Figure 6.1.

The general information about the database includes the database name, the in-stance name, the database version, and the fix pack level. If the database is in-stalled as a High Available Disaster Recovery (HADR) database, the detailedHADR status information will also be displayed here.

108


• Overview

• Database Manager

• Database

• Registry Variables

• Parameter Changes

• Database Partition Groups

• Buffer Pools

• Special Table RegardingRUNSTATS

• File Systems

• Data Classes

• Monitoring Settings

• Automatic Maintenance Settings

Figure 6.1: The Overview screen shows general information about the database and theoperating system.

The Database ManagerA number of configuration parameters are defined on the database manager (orinstance) level. These parameters control the database execution environment,database diagnostics and monitoring options, database security, system resourceutilization (CPU and memory), network connectivity, etc.

For some database manager configuration parameters, the database manager mustbe stopped (db2stop) and restarted (db2start) for the new parameter values totake effect. Other parameters can be changed online. These are calledconfigurable online configuration parameters. Some parameters support theAUTOMATIC value, which means the database manager will tune the runtimevalue automatically based on the current system workload and the system re-source available.

Choose Configuration� Database Manager, and you will be able to view andmaintain database manager configuration parameters. All parameters are nicelygrouped in a tree structure, as shown in Figure 6.2. To view parameters belong-ing to a particular group, such as Memory, click its name to expand the tree.

Each parameter has a short description, a technical name, the current value, andthe deferred value. The current value is the active value stored in the memory,while the deferred value is the value stored in the configuration file on the disk,which will not take effect until the database manager (or instance) is restartednext time.

109


Note that some parameter values are associated with a unit. For example, the pa-rameter INSTANCE_MEMORY is measured in 4KB unit. If this parameter is set to250,000, its actual value is 250,000 multiplied by 4KB, i.e., 1,000MB.

To change a parameter value, follow these steps:

1. Double-click the parameter that you want to change. Detailedinformation about this parameter is displayed in a new group box in thelower part of your screen, as shown in Figure 6.3.

110


Figure 6.3: Detailed information about a parameter is displayed here.

Figure 6.2: View and maintain database manager configuration parameters here.

2. Click (the “Display <-> Change” button), and enter the newconfiguration parameter values. Some configuration parameters areenabled for automatic value adjustment. In this case, the checkboxAUTOMATIC is displayed. If you select it, the value will automatically bemaintained by DB2. You can also enter the new value, which will beused as the starting value for automatic adjustment.

3. Click the Execute Change button to confirm the change.

Table 6.1 lists some parameters that require tuning after the system is installed.For other parameter settings, please refer to the SAP notes mentioned earlier inthis chapter.

Table 6.1: Examples of Database Manager Configuration Parameters

Technical Name Description Recommended Value

INSTANCE_MEMORY This parameter specifiesthe maximum amount ofmemory that can beallocated for a databasepartition.

<Value> 4KB

The <value> should be the totalamount of physical memory thatis allowed to be consumed bythe database manager. In apartitioned database, this is thememory allocated by a singlepartition.

SHEAPTHRES This parameter is aninstance-wide soft limiton the total amount ofmemory that can beconsumed by privatesorts at any given time.

0

When this parameter is set tozero, no private sort will occur.All sort operations should bedone in the database sharedmemory, not in the agent privatememory. By allocating sort heapfrom the database sharedmemory, it allows the sort heapsize to be tuned by DB2automatically.

111


Table 6.1: Examples of Database Manager Configuration Parameters


MON_HEAP_SZ This parameterdetermines the amountof the memory, in pages,to allocate for databasesystem monitor data.

AUTOMATIC

The monitor heap can increaseas needed until theinstance_memory limit isreached.

INTRA_PARALLEL This parameter specifieswhether the databasemanager can useintra-partition parallelism.

This parameter should only beturned ON in SAP NetWeaverBW and related systems, suchas APO and SEM, based on asingle-partition database.

MAX_QUERYDEGREE This parameter specifiesthe maximum degree ofintra-partition parallelismthat is used for any SQLstatement executing onthis instance of thedatabase manager.

1 or <value>

If INTRA_PARALLEL = NO, thisparameter should be one.Otherwise, use a value equal tothe number of CPUs allocated tothe database partition.

The Database

There are a large number of configuration parameters defined on database level.Some parameters are informational, as they show the database attributes (such asdatabase codepage) and the database states (such as backup pending androll-forward pending). Most of the other parameters are configurable, as they areused to control system resource utilization (CPU, memory, and disk I/O), transac-tion logging, log file management, database automatic maintenance, databasehigh availability, and so on.

In a partitioned database (DPF), each partition is an independent runtime envi-ronment because DPF is based on the share-nothing architecture. Therefore, eachpartition of the same database has its own set of configuration parameters. Thevalue for the same database configuration parameter could vary from partition to

112


partition, although it is recommended to maintain uniform parameter valuesamong all partitions belonging to the same database.

Like the database manager configuration parameters (DBM CFG), most of data-base parameters (DB CFG) are configurable online. In addition, many parameterscan be simply set to AUTOMATIC so that DB2 will tune the values dynamically.

In particular, starting in V9.1, DB2 introduced a new memory-tuning feature thatsimplifies the task of memory configuration by automatically setting values forseveral memory configuration parameters. This feature is called Self-TuningMemory Manager (STMM). When enabled, the memory tuner dynamically dis-tributes available memory resources among several memory consumers, includ-ing the sort heap, the package cache, the lock list, and the buffer pools, inresponse to significant changes in workload characteristics.

Choose Configuration� Database, and you will be able to view and maintaindatabase configuration parameters. As you can see in Figure 6.4, all parametersare nicely grouped in a tree structure similar to the database manager configura-tion parameters. The same interface layout is used to view and modify the param-eter values.

113


Figure 6.4: All parameters are grouped in a tree structure.

You might also notice the little Show Value History icon beside the configu-ration parameters in the Self-Tuning Memory Manager group. By clicking theicon, you will see the value change history for the corresponding parameter. Theresult for a parameter is displayed in a separate window. By default, the valuehistory information is displayed as a chart, as shown in Figure 6.5. To switch to atabular view, click the List button. To limit the history time frame, choose Fromdate and/or To date.

In a multi-partitioned database environment, each database partition has its ownset of database configuration parameters. In general, we recommend that all datapartitions have the same parameter values if the workload and the system re-sources are the same on these partitions.

With the DBA Cockpit, it is easy to compare the database configuration parame-ter settings for multiple partitions. On the Configuration: Database–Displayscreen, click the button. Select the partitions that you want to comparein the Select Partitions to Compare pop-up window, and then click Compare. A

114


Figure 6.5: Clicking the Show Value History icon for an STMM configuration parameter dis-plays a chart of value history information.

Configuration: Database–Compare Partitions screen will be displayed, as shownin Figure 6.6.

115


Figure 6.6: Clicking the Compare button on the Database–Display screen displays thiscomparison.

Table 6.2 highlights some important parameters related to database memorysettings.

Table 6.2: STMM (Self-Tuning Memory Manager) Parameters


DATABASE_MEMORY This parameter specifies theamount of memory that isreserved for the database sharedmemory region. If this amount isless than the amount calculatedfrom the individual memoryparameters (for example,LOCKLIST, utility heap,bufferpools, and so on), the largeramount will be used.

AUTOMATIC

When it is set to AUTOMATIC,the initial database sharedmemory allocation is theconfigured size of all heaps andbuffer pools defined for thedatabase. The memory will beincreased as needed.

LOCKLIST This parameter indicates theamount of memory that isallocated to the lock list. There isone lock list per database, and itcontains the locks held by allapplications concurrentlyconnected to the database.

AUTOMATIC

This parameter is enabled forself-tuning.

MAXLOCKS This parameter defines apercentage of the lock list held byan application that must be filledbefore the database managerperforms lock escalation.

AUTOMATIC

This parameter is enabled forself-tuning

.The value of LOCKLIST is tuned,together with the MAXLOCKSparameter. Therefore, enablingself-tuning of the LOCKLISTparameter automatically enablesself-tuning of the MAXLOCKSparameter.

PCKCACHESZ This parameter is used forcaching sections of static anddynamic SQL statements on adatabase.

AUTOMATIC

This parameter is enabled for selftuning.

116


Table 6.2: STMM (Self-Tuning Memory Manager) Parameters


SORTHEAP This parameter defines themaximum number of memorypages to be used for sorts.

AUTOMATIC

This parameter is enabled forself tuning. The self-tuning ofSORTHEAP is allowed onlywhen the sort heap isallocated from the databaseshared memory, i.e., sharedsorts.

SHEAPTHRES_SHR This parameter represents asoft limit on the total amount ofdatabase shared memory thatcan be used by sort memoryconsumers at any one time.

AUTOMATIC

This parameter is enabled forself-tuning. See more detailson the database managerconfiguration parameterSHEAPTHRES in Table 6.1.

SELF_TUNING_MEM This parameter determineswhether the memory tuner willdynamically distributeavailable memory resources,as required between memoryconsumers that are enabledfor self-tuning.

ON

This parameter enablesmemory self-tuning. Becauseself-tuning redistributesmemory between differentmemory areas, there must beat least two memory areasenabled for self-tuning tooccur.

Registry VariablesTwo types of variables can be maintained in the Registry Variables section of da-tabase configuration: operating system environment variables and DB2 profileregistry variables. These variables control how to start up and run the databasemanager. Only a handful of variables need to be set in the OS environment. Mostvariables can now be set in the centrally controlled DB2 profile registry.

117


Environment Variables

In an SAP database instance, you will find some DB2-related OS environmentvariables being defined in db2<dbsid>, <sid>adm, and sap<sid> user profiles,such as these:

DB2INSTANCE=db2<dbsid>INSTHOME=/db2/db2<dbsid>

These OS environment variables are defined automatically during the SAP in-stance installation, and will not be changed. Hence, no ongoing maintenance isrequired on the environment variables.

Registry Variables

Registry variables are centrally controlled by DB2 profiles. There are four profileregistries:

• The DB2 Instance Level Profile Registry—Most of the DB2 environmentvariables are placed within this registry. The environment variable settingsfor a particular instance are kept in this registry. Values defined in thislevel override their settings in the global level.

• The DB2 Global Level Profile Registry—If an environment variable is notset for a particular instance, this registry is used. This registry is visible toall instances pertaining to a particular copy of DB2 ESE. One global-levelprofile exists in the installation path.

• The DB2 Instance Node Level Profile Registry—This registry levelcontains variable settings specific to a database partition in a partitioneddatabase environment. Values defined in this level override their settingsat the instance and global levels.

118


• The DB2 Instance Profile Registry—This registry contains a list of allinstance names associated with the current copy. Each installation has itsown list. You can see the complete list of all the instances available on thesystem by running db2ilist.

DB2 configures the operating environment by checking for registry values andenvironment variables, and resolving them in the following order:

1. Environment variables set with the set command (or the export

command on UNIX platforms).

2. Registry values set with the instance node level profile (using the db2set

-i <instance name> <nodenum> command).

3. Registry values set with the instance level profile (using the db2set -i

command).

4. Registry values set with the global level profile (using the db2set -g

command).

Choose Configuration� Registry Variables, and you will be able to viewthese variables.

119


As you can see in Figure 6.7, the environment variables and the DB2 profile reg-istry variables are displayed on the same screen. They are identified by different“scopes.”

You will notice that the first registry variable is DB2_WORKLOAD, which is an ag-gregate variable. An aggregate registry variable allows several registry variablesto be grouped as a configuration that is identified by another registry variablename. As of DB2 9.5, the only valid aggregate registry variable isDB2_WORKLOAD. When DB2_WORKLOAD is set to the value SAP, DB2 engine im-plicitly sets a list of registry variables, depending on the current DB2 version andfix pack, to the values that are optimized for SAP systems. These variables,shown in Figure 6.8, can influence different areas of the database manager, suchas the DB2 optimizer, locking behavior, table object creation, and MDC usage.

These variables and their respective values are chosen by the SAP and IBM DB2development team to optimize the database manager for SAP applications, basedon the team’s customer experience and knowledge of the SAP applications. Theycannot be changed in the DBA Cockpit screen because they are not intended tobe tuned by customers. Some of these variables are even undocumented. Theworkload values can be superseded by explicitly setting these registry variablesto different values. However, this should only be done on the advice of SAPglobal support or IBM DB2 support, to address a specific need. In general, SAPcustomers only need to ensure DB2_WORKLOAD is set to SAP.

120


Figure 6.7: Environment variables and the DB2 profile registry variables are displayed onthe same screen.

Parameter Changes

Choose Configuration� Parameter Changes, and you will be able to view thecurrent and previous settings of the registry variables, database manager, and da-tabase configuration parameters. You can also view the date and time of thechange. This feature can help DBAs keep track of the parameter’s changehistory.

The initial screen, shown in Figure 6.9, only displays the active values for thevariables and configuration parameters. To see the change history, select Historyin the Parameter field. You can also specify the period of the change history, aswell as the Parameter Type, which can be set to either Registry Variables, DBManager, or Database.

121


Figure 6.8: Here is the DB2 workload optimized for SAP.

The parameter change history data is collected by a standard DBA job, “Collec-tion of DB/DBM Config History,” on an hourly basis. The data collected is savedin an SAP table and can be displayed on this screen.

Database Partition GroupsIn an SAP NetWeaver BW or BW-based system, you can use the DB2 databasepartitioning feature (DPF) to deploy the SAP database on multiple partitions.This supports the high performance and scalability required by a large datawarehouse.

122


Figure 6.9: The initial Parameter Changes screen displays the active values for the variablesand configuration parameters.

In a multi-partitioned database, you can use a partition group to define a set ofpartitions, on which a table space can be created. A table created within that tablespace can be distributed across this group of partitions.

Choose Configuration� Database Partition Groups, and you will be able toview and maintain database partition groups.

By default, the SAP installation program (SAPinst) will only create a databasewith a single partition (partition number 0000). Therefore, all predefined partitiongroups will be defined on this partition initially, as shown in Figure 6.10.

After you add a new partition, you can use the Edit button on this screen to mod-ify the existing partition group, or use the Add button to define a new partitiongroup. You can also use the Delete button to remove a partition group on whichno table space exists.

Buffer Pools

A buffer pool is an area of main memory that has been allocated by the databasemanager for the purpose of caching table and index data as it is read from disk. ADB2 database can have one or multiple buffer pools.

123


Figure 6.10: All predefined partition groups will be initially defined on parti-tion 0000.

Unlike other memory pools in the database, a buffer pool is considered a data-base object, and its size is not controlled by a configuration parameter. To createa new buffer pool, change the size of an existing buffer pool, or delete an existingbuffer pool, choose Configuration� Buffer Pools.

By default, the SAP installation program (SAPinst) creates a default buffer poolnamed IBMDEFAULTBP, with a 16K page size, as shown in Figure 6.11. Bufferpools usually take up the biggest portion of the database shared memory. Youcan specify a buffer pool size either to a fixed size or to AUTOMATIC. If the bufferpool size is set to AUTOMATIC, and STMM is enabled, the actual buffer pool sizewill be tuned by DB2 automatically, in response to workload requirements.

When you create a new table space, you need to associate it with a buffer pool ofthe same page size. Therefore, if you have table spaces created on different pagesizes, you have to create multiple buffer pools corresponding to those page sizes.

In a partitioned database, a buffer pool will be created on all database partitions,by default. However, you can also specify the partition group in which a bufferpool will be created.

To view the buffer pool size, page size, associated partitions, and table spaces,double-click the buffer pool from the list shown in Figure 6.11. Detailed informa-tion about the buffer pool will be displayed, as shown in Figure 6.12.

124


Figure 6.11: This is the default buffer pool.

Special Tables Regarding RUNSTATSBefore a SQL statement can be executed by DB2, it needs to be compiled, so thatan execution plan can be generated by the DB2 optimizer. To generate an effi-cient execution plan, the optimizer needs to have intimate knowledge about thetables involved in the SQL statement, such as the table size, table cardinality, anddata distribution. This information is called table statistics. Table statisticschanges when table content is modified, for example, when new rows are in-serted, or existing rows are updated or deleted. Hence, the table statistics needs tobe refreshed from time to time, so that the optimizer has up-to-date informationto decide on the execution plan.

Table statistics can be refreshed manually by using DB2’s RUNSTATS command,or automatically by using DB2’s automatic statistics feature. The updated statis-tics will be stored in the database catalog tables.

125


Figure 6.12: The buffer pool’s detailed information is displayed here.

We recommend that you enable DB2 automatic statistics feature for a SAP sys-tem. To do this, either update the database configuration parameterAUTO_RUNSTATS, or select Configuration� Automatic Maintenance Settingin the DBA Cockpit.

There are some special tables whose cardinality and content can vary greatly in runtime. These tables are called volatile tables. For volatile tables, statistics data col-lected by RUNSTATS often becomes inaccurate. Therefore, the statistics of these ta-bles should not be collected and should not be used by the optimizer. Volatiletables are marked in the DB2 system catalog table, so that the optimizer can iden-tify these tables. The automatic statistics feature will not apply to these tables.

To mark a table as volatile, use DB2’s ALTER TABLE…VOLATILE command. Al-ternatively, in the DBA Cockpit, select Space� Single Table Analysis�Runstats Control.

To see a list of volatile tables, choose Configuration� Special Tables Regard-ing RUNSTATS. A list similar to Figure 6.13 will be displayed.

126


Figure 6.13: A list of volatile tables is shown here.

File Systems

Choose Configuration� File Systems, and a list of file systems is displayed, asshown in Figure 6.14. The information displayed on this screen can help you todetermine how much free space is available in these file systems. (This functionis not available for systems monitored using a remote database connection.)

Data Classes

A data class is used by the SAP DDIC (Data Dictionary) to define the physicalarea of the database (i.e., the table space) in which the table should be created.On DB2 LUW databases, each data class is mapped to two table spaces, the DataTablespace and the Index Tablespace.

This function can be used to maintain the relationship between a data class andDB2 table spaces. It is only available for SAP ABAP systems.

Choose Configuration� Data Classes. A list of SAP ABAP data classes andtheir corresponding DB2 table spaces is displayed, as shown in Figure 6.15. Onthis screen, you can click the Edit button to modify the data class and tablespaces mapping, the Add button to create a new data class as well as its associa-tion to table spaces, or the Delete button to drop a data class.

127


Figure 6.14: The File Systems screen can help you to determine how much free space isavailable.

A table space must be created before it can be associated to a data class. To cre-ate a table space from the DBA Cockpit, select Space� Tablespaces. A newdata class name must also conform to SAP naming convention. (For details, see“SAP Note 46272.”)

Monitoring Settings

Choose Configuration�Monitoring Settings to set the user-defined functionlibraries’ (UDFs’) path, and change the retention periods for the history data.

There are a few DB2 UDFs developed by SAP. They are required for monitoringremote DB2 database system through the DBA Cockpit. These UDFs are pack-aged in a shared library file named db6pmudf, which is part of the SAP kernel.On the Configuration: Monitoring Settings screen, you need to set the path forthis library, as shown in Figure 6.16. Normally, this path should be the standardSAP kernel path, “/usr/sap/<SID>/D*/exe.” To be sure about this, click the Testbutton to test the UDF library loading.

128


Figure 6.15: A list of SAP ABAP data classes and their corresponding DB2 table spaces isdisplayed here.

During the SAP installation, SAP defines a number of standard DBA jobs, suchas “Collection of DB Performance History,” “Collection of DB/DBM ConfigHistory,” and “Collection of Bufferpool History.” The history data collected bythese jobs will be saved to internal SAP tables. You can specify the retention pe-riod of history data on the screen shown in Figure 6.17.

It is also a good practice to archive the DB2 diagnostic log file “db2diag.log”regularly, so that it will not grow to an unmanageable size. Do this by clicking

129


Figure 6.17: Specify the retention period of history data here.

Figure 6.16: Set the path for the UDFs’ library here.

the Switch Weekly checkbox for this file. The current “db2diag.log” will besaved under a new name with a timestamp, and a new “db2diag.log” file will becreated automatically.

Automatic Maintenance SettingsDB2 provides automatic maintenance capabilities for performing database back-ups, keeping statistics current, and reorganizing tables and indexes as necessary,to reduce the cost of database administration. Performing maintenance activitieson your databases is essential in ensuring that they are optimized for performanceand recoverability. These automatic maintenance capabilities are fully integratedinto the SAP DBA Cockpit. To enable and configure these capabilities, use thefunctions provided by Configuration� Automatic Maintenance Settings.

Automatic BackupsAutomatic database backups help to ensure that your database is backed up prop-erly and regularly, so that you don’t have to worry about when to back up orknow the syntax of the DB2 BACKUP command. An automatic database backupcan be either online or offline. It is triggered by predefined conditions, based onthe considerations of database recoverability and performance impact. Using theStarting Conditions area of the Automatic Backup tab shown in Figure 6.18, youcan choose a predefined condition or customize the condition by specifying thenumber of days and amount of log space created since the last backup. You alsoneed to specify the backup media.

130


Figure 6.18: Choose a predefined starting condition or customize the condition here.

In general, automatic backup should be enabled on a small database or on devel-opment and test systems. For a production database, schedule a backup job on aspecified time and frequency through the DBA Cockpit’s Jobs� DBAPlanning Calendar.

Automatic RUNSTATSAutomatic statistics collection can improve the database performance by main-taining up-to-date table statistics. This feature is fully supported and works verywell with SAP systems. Therefore, you should enable automatic RUNSTATS forall SAP systems. Automatic statistics collection is a background process that runsapproximately every two hours. The process evaluates all active tables, to checkwhether or not tables require statistics to be updated. It then schedules RUNSTATS

jobs for tables whose statistics are out of date. The background RUNSTATS jobs al-ways run in online and throttled mode, which means they do not affect the normal ac-cess to the tables.

By default, automatic RUNSTATS jobs collect the basic table statistics with distri-bution information and detailed index statistics using sampling. (The RUNSTATS

command is issued, specifying the WITH DISTRIBUTION and SAMPLED DETAILED

INDEXES ALL options.) You can customize the type of statistics collected by en-abling statistics profiling, which uses information about previous database activ-ity to determine which statistics are required by the database workload. You canalso customize the type of statistics collected for a particular table by creatingyour own statistics profile for that table. As you can see in Figure 6.19, volatiletables are excluded from automatic RUNSTATS.

131


Figure 6.19: Volatile tables are excluded from automatic RUNSTATS.

Automatic REORGAutomatic reorganization determines the need for reorganization on tables andindexes by using the REORGCHK formulas. It periodically evaluates tables and in-dexes that have had their statistics updated, to see if reorganization is required. Ifso, it internally schedules reorganization on the table and indexes.

Automatic reorganization on a table is always performed in offline mode, whichmeans any write access to the table currently being reorganized is not allowed. Onthe other hand, automatic reorganization on an index can be performed in either on-line or offline mode, which can be selected on the tab shown in Figure 6.20.

Since the reorganization of large tables will generally take a long time, youshould enable automatic reorganization only on small tables. SAP has defined apolicy to select tables for automatic reorganization. The policy is based on the ta-ble size. The default table filter size is set to 1GB, although this can be changedon the Automatic REORG tab. A filter size of 1GB allows tables smaller thanthat to be qualified for automatic reorganization. Larger tables would need to bereorganized manually, using the DBA Cockpit’s Jobs� DBA Planning Calen-dar or Space� Single Table Analysis. If you want to specify a more granular ta-ble filter policy, you need to use the DB2 Control Center tool.

132


Figure 6.20: Set automatic reorganization options here.

All automatic maintenance activities will only occur within a specified time pe-riod, called the maintenance window. An online maintenance window is used tospecify the time period for performing online activities, such as automaticRUNSTATS, online automatic database backup, or online automatic index reorga-nization. An offline maintenance window is used to specify the time period forperforming offline activities, such as offline automatic database backup andoffline table reorganization. Both online and offline maintenance windows can bedefined on the General tab of the Automatic Maintenance Settings screen, shownin Figure 6.21.

SummaryDatabase configuration is critical to system performance, and to ensure smoothoperations. In an SAP environment, the database configuration must be tuned tomeet the demands of SAP applications, and to be consistent with SAP systemconfiguration, such as SAP Data Classes and the ABAP Dictionary (DDIC).

133


Figure 6.21: Set automatic maintenance settings here.

The SAP DBA Cockpit provides easy tools to help maintain every area of data-base configuration and the database-specific SAP configuration. The jointIBM-SAP development team has made a huge effort to optimize DB2 databasesfor SAP applications and to enhance the autonomic computing features of DB2database. The goal is to make a DB2 database a zero-administration database, sothat DBAs can concentrate on higher value work, and thus lower the total cost ofownership (TCO).

134


Chapter 7

The Alert MonitorAvoiding Air Turbulence

The DBA Cockpit for DB2 allows SAP DB2administrators to monitor their CCMS database alerts

and thresholds in the same transaction used for databasediagnostics and performance monitoring. Thus, the cockpit

makes it easier to maintain the health of your SAP database.

The CCMS alert monitors for the DB2 database are integrated into the Alertssection of the DBA Cockpit. All database alert monitoring, the alert mes-

sage history, and some alert configuration parameters are now easily accessiblehere. The monitors include thresholds for disk space consumption, memory utili-zation, buffer pool quality, locking, database backup, and log archival. If the da-tabase exceeds the defined thresholds, emails can automatically notifyadministrators, who can then implement corrections before the system is affected.

First, however, background monitoring must be activated. Execute transaction RZ21

and click Technical Infrastructure� Local Method Execution� ActivateBackground Dispatching. Then, return to RZ21, in the Methods section, selectMethod Definitions and click the Display Overview button. Search for, and dou-ble-click either CCMS_OnAlert_Email or CCMS_OnAlert_Email_V2. Config-ure the Parameters tab with the proper email sender, recipients, subject, etc. Then,the specified recipients will be alerted via email when an alert threshold is crossed.

135

The CCMS system in SAP comes with pre-configured alert categories, parame-ters, and thresholds for the DB2 database. Experienced users may modify thisconfiguration or change threshold values in transaction RZ21. In most cases,though, we recommend keeping the default values for these thresholds.

The Alert MonitorThe DBA Cockpit provides an overview of all database alert monitor elementsunder Alerts Alert Monitor. This screen, shown in Figure 7.1, displays an easilyreadable, color-coded, hierarchical list of alert categories and monitors for allDB2 database partitions on the current SAP system. Elements operating in theirnormal range appear with green squares. The warning thresholds are flagged yel-low, and the error thresholds are flagged red.

Administrators can drill down through the categories to the individual monitor el-ements, see status messages, and compare current values with the assigned

136

CHAPTER 7: The Alert Monitor

Figure 7.1: The Alert Monitor displays a clear overview of overall system health.

threshold values. For more detail, load the CCMS Monitor Sets (transactionRZ20), and drill down through SAP CCMS Monitor Templates� Database�DB2 Universal Database for NT/UNIX. You will be able to view the completemonitor element details for the database.

The Alert Message LogSAP saves the history of alert messages in the Alert Message Log, shown in Fig-ure 7.2. By default, this screen displays all of the error and warning alerts fromthe previous week, ordered by date and time. The Summary section provides anoverview of the number of alerts for each category and severity. The Current Se-lection provides the ability to filter alert logs based on Severity, Category, Ob-ject, and Attribute. Historical alert messages can be accessed for very specificobjects, to identify any trends or recurring issues.

137


Figure 7.2: The Alert Message Log displays the history of alert messages.

Alert ConfigurationThe Alert Configuration screen provides access to the alert threshold propertiesfrom transaction RZ21. The main screen, shown in Figure 7.3, provides a list ofall alert monitors and threshold values.

Double-click any individual row to see the detailed information on that monitorelement, including threshold value details and data collection schedules. Throughthis screen, shown in Figure 7.4, you can enable or disable email notification forcertain monitor thresholds, and activate or deactivate monitor elements. For ele-ments not related to performance (such as the backup elements), the alert thresh-olds can also be configured within the DBA Cockpit. However, for any of theelements related to performance, attribute and threshold value maintenance mustbe done within transaction RZ21.

138


Figure 7.3: The Alert Configuration screen displays a list of database alert monitor elementsfrom SAP CCMS.

SummaryThe integration of the SAP CCMS database monitor elements into the DBACockpit alert monitor simplifies the process of proactive problem analysis. Ev-erything is easily visible within a single transaction, and automatic alert notifica-tion ensures that the proper people are notified as soon as warning and errorthresholds are crossed. This allows problems to be caught and prevented beforethey affect the system.

139


Figure 7.4: Alert thresholds can be changed here for elements not related to database per-formance.

Chapter 8

Database DiagnosticsDealing with Air Turbulence

The database diagnostics in the DBA Cockpit for DB2give DB2 database administrators an integrated set

of powerful tools for problem determination,application optimization, and reference documentation.

One of the tasks that a DBA must perform every day involves monitoringthe health of the database to look for possible problems and inconsisten-

cies. No database is perfect, and administrators will face a challenge sooner orlater. What differentiates database managers from one another is the way theydeal with challenges, based on the mechanisms and tools available. In that sense,DB2 and SAP offer a variety of tools that can help the DBA quickly identify, di-agnose, and solve a problem.

The deep integration of DB2 and SAP is showcased again in the DBA Cockpit’sdiagnostic option. It is composed of many tools that you can use to troubleshootdiverse problems, such as database security, query performance, concurrency,and inconsistencies between ABAP and database objects.

140

The Audit LogThe Audit Log, shown in Figure 8.1, keeps track of actions executed against thedatabase from the DBA Cockpit. Such changes include SQL statements (whetherexecuted successfully or not); configuration changes made at the database man-ager (instance) and database level; and table space creation and deletion. Changesperformed using native DB2 tools (CLP for instance) are not tracked here.

By default, changes that happened in the current week are displayed. However,the calendar can be used to choose a different week. DBAs can also change thenumber of days for the messages. The fields listed in the Audit Log are explainedin Table 8.1.

141

CHAPTER 8: Database Diagnostics

Figure 8.1:The Audit Log displays information about actions performed at the databaselevel.

Table 8.1: Audit Log Fields

Field Meaning

Date Start date of action

Time Start time of action

System System affected

Action Type of action

Command Command (SQL, add table space, delete table space, editconfiguration)

Object Object modified

User SAP user who performed the action

The EXPLAIN OptionAs described in Chapter 2, the DBA Cockpit offers many different views under thePerformance options, which allow the DBA to quickly analyze whether the systemis performing optimally. Under normal circumstances, the key database perfor-mance indicators displayed by ST04 give the DBA a very good idea of what needsto be tuned in the database to maintain good overall performance in the system.

However, there are special situations that can bring the performance down for aparticular application, or sometimes even affect the performance of the entiresystem. In such cases, the DBAs must apply their knowledge to analyze and re-solve the performance issue using diagnostic tools, historic data for comparison,and their best judgment.

One of the most important parts of performance troubleshooting is isolating theproblem. In many cases, a performance problem can be isolated to a poorly per-forming SQL statement. This is the granularity for which you should aim. Oncethe bad SQL is discovered, you can use diagnostic tools to analyze it deeply. TheEXPLAIN option of the DBA Cockpit plays a major role here. In DB2, every DML(select, insert, update, and delete) statement sent by an application goes through a

142


compilation phase. One of the components involved in this phase is the DB2cost-based optimizer.

For query processing, one of the tasks performed by the optimizer is to develop di-verse strategies, called access plans, to process the SQL statement. The optimizerattributes a certain cost (optimizer’s best estimate of the resource usage for a query)to each plan, using an arbitrary IBM unit called timerons. The optimizer thenchooses the plan with the lowest cost, and follows its execution strategy.

Of course, the optimizer chooses the plan based on the information available, soproviding correct information is vital for a good optimizer decision. Some dataused by the optimizer include the following:

• Statistics in system catalog tables. (If statistics are not current, update themusing the RUNSTATS command or configure the AUTO RUNSTATS featurethrough the DBA Cockpit.)

• Configuration parameters.

• Bind options.

• The query optimization class.

• Available CPU and memory resources.

The execution strategy can include such factors as which objects will be used toexecute the query (index or table scan), the join methods (nested loop, hash,merge, etc.), whether the query involves multiple tables, the access order of theobjects, and the use of auxiliary tables.

The EXPLAIN option of the DBA Cockpit allows the administrator to generate theaccess plan used by the optimizer in a particular query. Based on this informa-tion, you can study the internal characteristics of the objects involved, and takethe proper actions. Some of these actions can include the following:

• Statistics collection of objects included in the plan—Outdated statisticsinformation might lead the optimizer to choose the wrong plan. Forinstance, it might decide to run a full table scan rather than using an indexbecause it doesn’t have the correct row count information.

143


• Table or index reorganization—Tables and indexes get fragmented overtime. This might prevent the optimizer from being able to select theoptimal access plan. For example, suppose a query that has beenperforming well suddenly starts to take a long time to execute. Bychecking the EXPLAIN output, you conclude that the optimizer is notchoosing the best index for the query. In this case, the optimizer might bepicking a different index because the optimal one has become toofragmented and contains more levels than the current one. Reorganizingthe original index will fix this problem.

• Creation of new indexes—By looking at the EXPLAIN output and analyzingthe predicates involved in the query, you might find that a new index willimprove execution time. The index advisor can also be used in thesesituations, which allows DB2 itself to offer recommendations about newindexes. (This is explained in more detail in the next section of this chapter.)

To access the EXPLAIN facility, choose Diagnostics� EXPLAIN. (Alterna-tively, you can call it from the Performance option, Performance Applicationsand Performance SQL Cache, or from transaction ST05.) Using DiagnosticsEXPLAIN, you can paste in a SQL statement, click the Explain button, and re-trieve an access plan similar to the one shown in Figure 8.2.

144


Figure 8.2: The EXPLAIN option allows you to display the SQL access plan.

Notice that the information in Figure 8.2 is displayed in a tree format, containingthe operators and objects used in the query. The cost of the access plan is alsodisplayed in timerons, as well as the optimization level and the degree ofparallelism.

A set of extra options is provided via buttons at the top of the screen. If you needto study the access plan in more detail, or if you need to collect data to sent toSAP support, use these buttons, as follows:

• Details—When you click this button, you will see very detailedinformation about the query execution plan. CPU speed, buffer pool size,optimization level, optimized statement, and estimated number of rows arejust some of the information displayed. If you select an operator, onlyinformation related to that operator is displayed.

• Optimizer—You might be able to change the access plan by specifyingoptimizer parameters, like the optimization level and query degree. Theseoptions can be accessed through the Optimizer button. Optimization levelsrange from zero to nine, and define how much optimization effort (use ofresources) is necessary to generate the access plan. The higher the number,the more resources the optimizer uses to create the access plan. The defaultoptimization level is five, which is adequate in most cases. Higheroptimization levels might be used in very complex queries, but thecompilation time and memory usage can increase significantly, as well. Inthis option, however, you might increase the optimization level andre-explain the query just to see if it would make a difference; no changesare actually made.

Another parameter that can be changed for testing purposes is the querydegree. A degree of one (the default) means that no intra-partitionparallelism (parallelism inside the partition) is used. A value greater thanthat might activate intra-partition parallelism, provided that thisfunctionality is activated at the database manager.

145


• DB Catalog—When you select a database object like a table or an indexand click this button, a window with the object’s characteristics isdisplayed. This information is retrieved from the DB2 system catalog,which is a set of internal tables that contain metadata information aboutthe database objects. Some tables used in this option are SYSCAT.TABLES,SYSCAT.INDEXES, and SYSCAT.COLUMNS.

• Dictionary—This button displays the ABAP dictionary definition for thetable chosen in the access plan.

• Test Execute—This button lets you execute a query using differentoptimizer options (which are set using the Optimizer button), so you cantest the real execution time of the query. Other pieces of information, likebuffer pool access and locks wait, are also provided.

• Tree Info—Additional information can be displayed or hidden in theaccess plan tree with this button.

• Edit—This button allows you to edit the original query and explain itagain.

• Collect—Sometimes, even an experienced DBA might need to seek helpdiagnosing a poorly performing query. The DBA Cockpit provides a veryconvenient way to collect the necessary information to send to SAPsupport. By clicking just one button, you can collect information, such asthe DB2 version, configuration files, table structure, statistics, and theexplain information. Each piece of information is copied to a file, so youcan zip them up and quickly send them to SAP support. This type offunctionally is also provided through the DB2 support tool, calleddb2support.

The New Version of EXPLAINThe DBA Cockpit also offers a new version of the EXPLAIN facility, developedon the WebDynpro technology. In this case, the EXPLAIN option is displayed in a

146


web browser, as shown in Figure 8.3. However, it contains basically the same op-tions as the traditional version.

Missing Tables and IndexesThe DBA Cockpit also allows administrators to do a consistency check in theSAP system. In SAP, objects like tables, indexes, and views are defined in theABAP dictionary, and then the necessary objects are created in the underlyingdatabase.

There might be some situations, however, in which the ABAP dictionary is not insync with the database. Some objects might be defined in the dictionary, butdon’t exist in DB2, and vice versa.

The administrator can use the Diagnostics option of the DBA Cockpit to check ifthere are any inconsistencies between the ABAP dictionary and the database.

147


Figure 8.3: Here is an access plan displayed in the new version of EXPLAIN.

Access this option by choosing Diagnostics�Missing Tables and Indexes.The results will look similar to Figure 8.4.

The information displayed in Figure 8.4 includes the following:

• Objects missing in the database—The ABAP dictionary might containobjects that do not exist in the database. This could be caused by an errorin the database during creation of the object or by somebody with enoughprivileges dropping an object after its creation. In this scenario, the DBACockpit allows the creation of the missing object in the database, thusavoiding transport errors.

• Unknown objects in ABAP dictionary—Objects that are not known by theABAP dictionary do not belong to SAP. These are objects created directlyat the database level. For this reason, the list displayed here is purelyinformational; no action can be taken from the DBA Cockpit. (Thisusually should not occur in SAP systems, because all objects shouldalways be created in the ABAP dictionary.)

148


Figure 8.4: Discrepencies between the ABAP dictionary and the database are displayedhere.

• Inconsistent objects—The definitions of objects (tables, indexes, andviews) in the ABAP dictionary might not be the same as in the databasecatalog, and vice versa. The database contains an internal catalog thatcontains the definition of all database objects, and in some cases, thismight not be in sync with the ABAP dictionary. The administrator shouldreview these inconsistencies and take action.

• Other checks—Other consistency checks are performed, includingchecking whether the primary indexes of the tables defined in the ABAPdictionary were created exclusively in the database instance, and whetherthere are objects in the SAP base tables that cannot be described (or notdescribed completely) in the ABAP dictionary.

• Optional indexes—This check is related to secondary indexes. It reportsmismatches between the ABAP dictionary and the database, regardingsecondary indexes.

Click the Refresh button to run a new consistency check.

The Deadlock MonitorDB2 uses internal memory structures called locks to provide concurrency controland prevent uncontrolled data access by multiple applications. Locks must be ac-quired by applications when they need to access or modify data. Occasionally,DBAs can face a situation called deadlock, when two or more applications aretrying to acquire locks that are not compatible with those already held by otherapplications. Each application is waiting for a lock that is owned by a differentapplication, but at the same time, the waiting application itself is holding a lockthat is wanted by others. In this situation, none of the applications can advanceuntil one gives up on a lock. Concurrency and performance problems will inevi-tably occur in systems with frequent deadlocks.

Although the consequence of many deadlocks is reflected in the database perfor-mance, the reason for their existence is mostly attributed to the applications that

149


are accessing and modifying the database. There are application developmentguidelines that specifically deal with avoiding deadlocks, including these:

• Perform frequent commits so locks can be released.

• Avoid lock escalations by not locking too many rows.

• Use less-strict isolation levels.

• Avoid too many reads before a write.

• Modify tables in a certain order in all applications.

On SAP systems, most deadlocks are caused by customized programs(Z-programs), rather than standard SAP code.

DB2 has mechanisms that monitor and resolve deadlock situations in specific in-tervals, dictated by the database configuration parameter DLCHKTIME. When adeadlock is detected, the database manager resolves the situation by randomlypicking one of the participating applications (the victim) to roll back, which al-lows the other application to continue.

In a system with many deadlocks, it is important to understand what might becausing these undesirable situations. The Deadlock Monitor option in the DBACockpit can help analyze past deadlocks and study the SQL statements involved,so that corrective actions can be taken. This feature is especially useful when thedeadlock can be reproduced. The DBA Cockpit displays the deadlock occur-rences in a user-friendly way, making them very straightforward to analyze anddiagnose.

Here are the steps to follow to display the deadlocks that must be analyzed:

1. Create the Deadlock Monitor.

2. Enable the Deadlock Monitor.

3. Analyze the information collected by the Deadlock Monitor.

4. Stop the Deadlock Monitor.

5. Reset or drop the Deadlock Monitor.

150


Creating the Deadlock MonitorIt is necessary to create a Deadlock Monitor, if one does not already exist in thesystem. Choose Diagnostics� Deadlock Monitor and click the Create Dead-lock Monitor button. If the system does not have a Monitor, a wizard will be usedto help create one, as shown in Figure 8.5. The wizard asks for some inputs, likethe buffer size for the monitor (28,000 pages is recommended) and the tablespace used for the tables written to by the monitor (a dedicated table space isrecommended).

Enabling the Deadlock MonitorOnce the Deadlock Monitor is created, it needs to be started. To do this, click theStart Monitor button.

Analyzing the Information CollectedAfter running the system for a while, you can check whether deadlocks were de-tected in the system using the Performance option of the DBA Cockpit. (See

151


Figure 8.5: Use the wizard to create the Deadlock Monitor.

Chapter 2 for more information.) If so, the information about these deadlocks canbe analyzed using the historic information collected by the Deadlock Monitor. Theinformation is displayed when the screen is refreshed or the Monitor is stopped.

As shown in Figure 8.6, the deadlocks recorded are displayed, and each occur-rence can be expanded into more detail. Information on each occurrence is con-tained in a root folder called “Deadlock Victim: <application that got rolledback>.” Inside the folder, there is a summary of the agents involved in the dead-lock. Information about the agents includes the client PID, host, authorization ID,and waiting lock information (table, type, mode, etc.). Special arrow buttons canbe used to expand and collapse the detailed information.

To find out about the SQL statements involved in the deadlock, click the State-ments History button. This information can also be viewed separately, for eachagent involved in the scenario. Click the Agent Details button, and the AgentDetails window opens. This window has two tabs:

152


Figure 8.6: This is an example of a deadlock situation captured by the Deadlock Monitor.

• Locks Held—This tab shows information about the locks held by the agentand the locks that are needed (waiting).

• Statement History—This tab lists the SQL statements executed by thisparticular agent.

The SQL statement history is one of the most important pieces of information todiagnose a deadlock scenario. As you can see in Figure 8.7, it contains the fullstack of SQL statements executed by the agent in the transaction involved in thedeadlock. By looking at the statements involved, the administrator can easily findwhich ABAP program or report generated the SQL, and then talk to the devel-oper of the application. The problem might not necessarily be caused by the pro-gram found here, but the developer and the administrator can work together tosee if more commit points can be introduced so locks are released faster, orwhether more significant changes need to be made.

153


Figure 8.7: The statement history information can also be viewed here.

Stopping the Deadlock MonitorGathering deadlock information constantly will cause an overhead in the system.Therefore, the administrator should only enable the Deadlock Monitor for the pe-riod of time needed to get information about deadlocks. To stop it, click the StopMonitor button.

Resetting or Dropping the Deadlock MonitorWhen a new study on deadlocks is necessary, the administrator can opt to deletethe old information collected (assuming that the old occurrences have beensolved) by clicking the Reset button. Afterwards, only the relevant, new informa-tion is displayed. The administrator can also drop the monitor by choosing theMonitor menu option and selecting Drop Monitor. If you drop the monitor, it willhave to be created again if another deadlock analysis is necessary.

The SQL Command LineDB2 offers a variety of tools that can be used to access the database. Probably themost frequently used of these tools is the Command Line Processor, also knownas the CLP. The CLP is a character-based interface that accepts multiple com-mands, including SQL statements.

The DBA Cockpit offers an interface to the CLP, which allows administrators torun SQL statements and some administrative commands. To access the interface,select Diagnostics� SQL Command Line. The administrative commands thatcan be executed through this interface are the ones supported by the ADMIN_CMD

stored procedure. This procedure is used by applications to run administrativecommands using the SQL CALL statement. Figure 8.8 shows an example of thecommands that can be executed in this interface.

154


The administrative commands in the following table are supported byADMIN_CMD. This interface will most commonly be used for SQL statements,since most administrative operations can be performed graphically using otheroptions of the DBA Cockpit. SQL commands not supported by the ADMIN_CMD

procedure will fail. SQL statements that modify data are not permitted, either.

155


Figure 8.8: You can execute SQL and administrative commands in the SQL CommandLine interface.

The Index Advisor

As explained earlier, the lack of proper indexes on a table can cause severe per-formance problems for a query or a set of queries. Depending on how heavily thetable is accessed, the performance degradation can spread to the entire system.

Thankfully, the DBA Cockpit comes to the rescue again. One of the most inter-esting features provided in the Diagnostics option is the Index Advisor. The In-dex Advisor is a subset of the DB2 Design Advisor. It is used to help you findbetter indexes to support your workload. You can use the Index Advisor to createvirtual indexes and to let DB2 recommend indexes for SQL statement.

156


• ADD CONTACT

• ADD CONTACTGROUP

• AUTOCONFIGURE

• BACKUP (online only)

• DESCRIBE

• DROP CONTACT

• DROP CONTACTGROUP

• EXPORT

• FORCE APPLICATION

• IMPORT

• INITIALIZE TAPE

• LOAD

• PRUNE HISTORY/LOGFILE

• QUIESCE DATABASE

• QUIESCE TABLESPACES FOR

TABLE

• REDISTRIBUTE

• REORG INDEXES/TABLE

• RESET ALERT CONFIGURATION

• RESET DATABASE

CONFIGURATION

• RESET DATABASE MANAGER

CONFIGURATION

• REWIND TAPE

• RUNSTATS

• SET TAPE POSITION

• UNQUIESCE DATABASE

• UPDATE ALERT

CONFIGURATION

• UPDATE CONTACT

• UPDATE CONTACTGROUP

• UPDATE DATABASE

CONFIGURATION

• UPDATE DATABASE MANAGER

CONFIGURATION

• UPDATE HEALTH NOTIFICATION

CONTACT LIST

• UPDATE HISTORY

Indexes Recommended by DB2Click the Recommend Indexes button in the Index Advisor to have DB2 recom-mend indexes for the SQL statement specified in the text field.

Creating Virtual IndexesA virtual index is a user-defined index that only exists “virtually” within the in-dex advisor. It does not exist yet in the database. To create a virtual index in theIndex Advisor, click the Add Virtual Index button. As shown in Figure 8.9, anew window pops up to specify the schema, table, and columns that are part ofthe virtual index.

After defining virtual indexes, you can explain the query again and have theoptimizer consider the virtual indexes, as well as the existing ones, when buildingthe access plan. If the optimizer selects a virtual index (whether user-defined or

157


Figure 8.9: Use the Index Advisor to define a virtual index.

recommended by the Index Advisor), you can create such an index in the data-base, with the touch of a button.

In Figure 8.10, for example, the Index Advisor is recommending one new indexto support the execution of the query, and there is one user-defined virtual index.

Right beneath the indexes is an EXPLAIN button, which can be selected tore-explain the query using different options:

• Only existing indexes

• Existing and recommended indexes

• Existing, recommended, and user-defined indexes

158


Figure 8.10: The EXPLAIN option is shown here with existing, recommended, anduser-defined indexes.

You can compare the plans and the costs (in timerons), and based on the EXPLAIN

outputs, decide whether or not to create the indexes in the database and theABAP dictionary. To do that, just click the appropriate button (the magic wand)next to the recommended index, and fill out the index description information.

The Cumulative SQL TraceSAP business applications, such as ERP, CRM, and SRM, run on top of SAPNetWeaver, which is the SAP application platform. All SAP business applica-tions are database-independent, so that access to the data is transparent. The corecomponent of the SAP NetWeaver platform is the Web Application server. It isthe component that directly interfaces with the database. Therefore, it has a layerof code that abstracts the differences of the native databases, and provides a com-mon database interface to higher layers of SAP code. This abstraction layer iscalled the Database Support Layer (DBSL). SQL statements coming from busi-ness applications go through the DBSL and are translated into native DB2 SQL(in most cases).

For this reason, tracing the DBSL layer can give the DBA a good idea of theSQL statements that can be affecting the performance of the database. SAP pro-vides a way to use a cumulative trace of the database interface, so that the infor-mation collected can be analyzed by the administrator later.

To use the cumulative trace, you must first activate it. There are two differentways to do this:

• Activate the trace dynamically via profile parameter. Run transaction RZ11

and enable the profile parameter dbs/db6/dbsl_cstrace =1.

• Activate the trace using an environment variable: DB6_DBSL_CSTRACE=1.

Note that you might have to restart the SAP system if all work processes are to betraced. Configuration through the profile parameter is dynamic, but notpermanent.

159


All SAP systems that use the database interface, and are now executed, writetrace data to the table DB6CSTRACE in the table space PSAPUSER1D. The datacollected can be analyzed directly in the DBA Cockpit, by selecting DiagnosticsCumulative SQL Trace. Alternatively, you can run report RSDB6CSTRACE usingtransaction SA38, and analyze the data from there.

No statements are displayed when the trace has never been activated. After thetrace is activated and SQL statements are being logged, click the Refresh buttonto refresh the window.

The actions PREPARE, EXECUTE, and FETCH are summed up in tabs, as shown inFigure 8.11, and can be evaluated separately.

To display more detailed information, double-click a line, or select a line andclick (the Details icon). The following information is displayed:

160


Figure 8.11: Trace information collected by the Cumulative SQL Trace facility helps DBAsin their performance monitoring activities.

• Statement information—Information is provided about the SQL statement,the application server where the statement was executed, and all of theABAP reports in which the statement can be found. The source code of theABAP report can also be accessed from here.

• Time histograms—Histograms display the distribution times of theselected SQL statement.

On this detailed view, the administrator has the option to run the EXPLAIN facil-ity. Click the button to display the access plan. (For more information onhow to activate the cumulative SQL trace, refer to “SAP Note 139286.”)

The DBSL Trace DirectorySAP provides two other ways to trace the Database Support Layer (DBSL), inaddition to the cumulative trace option: the sequential DBSL trace and the dead-lock DBSL trace. The cumulative trace is suitable for performance analysis workperformed over long periods of time (where information is aggregated). The se-quential and deadlock traces are mostly used for shorter periods of time, whenthe problem has been isolated to a certain degree.

The Sequential DBSL TraceThe sequential DBSL trace logs all important function calls sent from the data-base interface in R/3 programs (for example, disp+work, tp, R3trans, and so on)to the database. Trace data is logged in log files at the operating system level. Bydefault, the trace files are stored in the /tmp/TraceFiles directory on UNIX sys-tems or in the \usr\sap\TraceFiles folder on Windows systems.

The sequential trace can be activated using three different methods:

• Using transaction SM50 for individual work processes (disp+work)—FromSM50, select the work process to be traced, and choose Process� TraceComponents. Then, select trace level 3 and the component database

161


(DBSL). Run the transaction. The trace information will be logged in thework directory of the instance.

• For all processes of a LOGON session—This method allows tracing fordifferent SAP processes, like disp+work, tp, and saplicense. Theadministrator enables a set of environment variables for the <sid>adm user.Some variables include DB6_DBSL_TRACE, DB6_DBSL_TRACE_DIR,DB6_DBSL_TRACE_FLUSH, and DB6_DBSL_TRACE_STRING.

• Using SAP profile parameters—The trace can be activated using theprofile parameter dbs/db6/dbsl_trace = <tracelevel> (where 3 is thehighest trace level). The remaining optional parameters are set with theabove-mentioned environment variables.

Note that the trace directory must exist and be accessible, for all of these meth-ods. Refer to “SAP Note 31707” for more details on how to activate the sequen-tial DBSL trace.

The Deadlock Trace

As explained earlier, deadlocks can affect the concurrency and performance of adatabase. DB2 provides internal mechanisms to alleviate these unwantedscenarios.

The DBA Cockpit’s Deadlock Monitor can help analyze the occurrences of dead-locks. SAP provides another way to track deadlocks. The DBSL deadlock tracecan be enabled in the following ways:

• Dynamically activate the DBSL deadlock trace for all work processes viatransaction RZ11, by changing the profile parameterdbs/db6/dbsl_trace_deadlock_time = <seconds>. SAP recommends a timeinterval of 20 to 26 seconds. The other parameter isdbs/db6/dbsl_trace_dir = <tracepath>.

162


• Activate the trace for all processes of a LOGON session. Set the followingenvironment variables for user <sid>adm:DB6_DBSL_TRACE_DEADLOCK_TIME = <time in seconds> andDB6_DBSL_TRACE_DIR = <path>.

The default trace path is /tmp/TraceFiles for UNIX and \\sapmnt\TraceFiles forWindows. (Refer to “SAP Note 175036” for more information about the DBSLdeadlock trace.)

To access information on the sequential DBSL trace and the DBSL deadlocktrace, choose Diagnostics� DBSL Trace Directory in the navigation frame ofthe DBA Cockpit.

Figure 8.12 shows that the trace directory is set to the default, /tmp/TraceFiles. Asubdirectory <SID> is created under the trace directory, which is where the tracefiles are generated. Notice that there are sequential trace files(TraceFile<Appl-ID>.txt) and Deadlock Trace files (DeadlockTrc<App-ID>.txt)in this directory, since both traces are using the default directory. To see the con-tents of each file directly from here, double-click it.

163


Figure 8.12: You can see the trace files generated here.

Trace StatusSAP provides three different ways to trace the Database Support Layer: cumula-tive SQL trace, sequential DBSL trace, and deadlock trace. These traces work in-dependently of each other, so one trace can be activated despite the fact that theothers are disabled. They can also all be activated at the same time.

You can check if a cumulative DBSL trace is activated by checking whether newrecords are being inserted in table sap<SID>.DB6CSTRACE. For sequential anddeadlock traces, check whether files are being updated or created in the trace di-rectory. You can also check environment variables and profile parameters.

None of this is really necessary, however, because the DBA Cockpit provides avery convenient way to check which DBSL traces are active at the moment. Toaccess this information, just select Diagnostics� Trace Status.

In the example in Figure 8.13, you can see that all three DBSL traces are cur-rently activated. For the sequential trace, some options can be updated from thissame screen.

164


Figure 8.13: All three DBSL traces are currently activated here.

Besides checking the status of the traces, you can also activate and deactivatetraces dynamically from this window, by using the icon. The DBSL trace re-quires the Trace Level information before being activated, and the deadlock tracerequires the Detection Interval value.

The Database Notification LogSo far, you have seen many different diagnostic tools that can help solve specificproblems, like ABAP dictionary consistency, deadlocks, and performance. How-ever, there are other areas in the database that can potentially report a warning oran error. It would be not feasible to have additional options in the Diagnosticfolder for each one of them.

Therefore, to have an overall look at the health of the database, you can use twodiagnostic files. The first one is the Database Notification Log (also known as theAdministration Notification Log), which is located in the directory specified bythe DIAGPATH database manager configuration parameter. The name of the file is<instance name>.nfy. Since it is an ASCII file, it can be opened directly on thedatabase server machine, using an editor.

The DB2 database manager writes the following kinds of information to the Ad-ministration Notification Log:

• The status of DB2 utilities, such REORG and BACKUP

• Client application errors

• Service class changes

• Licensing activity

• Log file paths and storage problems

• Monitoring and indexing activities

• Table space problems

A database administrator can use this information to diagnose problems, tune thedatabase, or simply monitor the database.

165


To access the Database Notification Log directly from the DBA Cockpit, chooseDiagnostics� Database Notification Log. You can filter what messages getdisplayed by choosing the date and the starting time. You can also filter by theseverity of the messages, which can vary from informational to error.

The level of detail reported in the Database Notification Log is controlled by theNOTIFYLEVEL database manager configuration parameter. It ranges from zero tofour. The default value of three is appropriate for most systems.

The Database Diagnostic LogThe other diagnostic file used by DB2 is the Database Diagnostic Log(db2diag.log), which is probably the most important file used to troubleshootproblems with the database. This file is also located in the directory specified bythe DIAGPATH database manager configuration parameter. Its level of detail iscontrolled by the DIAGLEVEL database manager configuration parameter. TheDIAGLEVEL accepts values from zero to four as well, and the default value ofthree is suitable for most systems. A higher level (four) should only be used for avery short period of time and when explicitly requested by SAP support, since atthis level, DB2 records many details and the file can grow very quickly.

The db2diag.log file can grow very big even at the default level, so from time totime, the administrator should archive it. DB2 offers a tool for that, calleddb2diag. By using the –A option (db2diag –A), the current db2diag.log file gets atimestamp appended to it, and a new log file is created.

To access the contents of the db2diag.log file directly from the DBA Cockpit,choose Diagnostics� Database Diag Log. You can also filter which messagesto display. Filters are available for date, time, and severity of the message.

The db2diag.log can also be accessed directly on the database server machine, since itis an ASCII file. We usually recommend this method, since you can use OS com-mands like grep (in UNIX/Linux systems) to apply other filters on the db2diag.logfile. Alternatively, you can use the db2diag tool, which provides grep-like andtail-like functionality (among others), so more restrictive filters can be applied.

166


DB2 LogsThe DB2 Logs option, shown in Figure 8.14, is available in DB2 version 9.5.This option shows the combined information of the Database Notification Log,the Database Diagnostic Log, and the Statistics Log (information generated bythe autonomic computing daemon, db2acd). There are several filters you can ap-ply to display only a subset of the information:

• Log Facility—Choose from the main logs (Diagnostic and Notification),the Statistics Log, or all logs.

• Record Type—Choose from diagnostic records, event records, or allrecords.

• Minimum Impact Level—Choose from the options Critical, Immediate,Potential, Unlikely, None, or All.

• Messages From…To—Specify a range of date and time.

After applying the filters, press the Find button to refresh the messages.

167


Figure 8.14: Check the DB2 message logs here.

The Dump DirectoryDB2 uses an internal mechanism to collect diagnostic information automaticallywhen database errors occur. The term used for the set of diagnostic files collectedis First Occurrence Data Capture, or simply FODC. The files captured are lo-cated in the directory specified by the DIAGPATH database manager parameter.These are some of the files collected:

• Database Notification Log

• Database Diagnostic Log (db2diag.log)

• DB2 event logs

• FODC packages

• DB2DART directory

• STMM log directory

To access these diagnostic files in the DBA Cockpit, select Diagnostics�Dump Directory. To open a specific file, just double-click it. As shown in Fig-ure 8.15, the directory where these files are located (DIAGPATH) is also displayed.This gives you the option to log onto the machine where the database server re-sides, and access the files directly.

168


Figure 8.15: You can view the DB2 diagnostic files here.

The DB2 Help CenterYou can find a lot of documentation about DB2 online, including all the manuals,which can be downloaded in PDF format. However, you might spend a lot oftime searching for specific information, if each individual PDF file has to beopened and searched. For this reason, IBM has created an online tool called theDB2 Help Center (also known as the DB2 Information Center). The DB2 HelpCenter, shown in Figure 8.16, provides a searching capability based on keywordsacross all DB2 manuals, so minimal time is spent researching a command’s syn-tax or getting information about a certain database feature.

The DB2 Help Center can be accessed through a browser. It can also be accesseddirectly from the DBA Cockpit by choosing Diagnostics� DB2 Help Center.

SummaryJust like a pilot must deal with air turbulence during a flight, a DBA must dealwith problems that might occur in the database. The DBA Cockpit provides

169


Figure 8.16: The DB2 documentation can be viewed directly from the DBA Cockpit.

diverse tools to quickly diagnose the most common problems in a SAP database,such as ABAP consistency, SQL performance, and concurrency. For other prob-lems, the DBA Cockpit provides a convenient way to access FODC informationcaptured by DB2. Even novice DB2 administrators can easily access these vitalfiles without needing to log onto the database server machine and know theirlocations.

Troubleshooting database problems can be intimidating and time-consuming formost administrators, but the DBA Cockpit leverages the most important DB2 di-agnostic tools in an easy-to-use graphical interface. This significantly simplifiesproblem analysis and reduces resolution time.

170


Chapter 9

New FeaturesFlying into the Future

SAP and IBM continue to jointly develop new technologyand integrate new DB2 features into the DBA Cockpit.

DB2 SAP users benefit from having timely access to thelatest and greatest database technology, integrated

seamlessly into their SAP applications.

New technology is continuously being developed by both SAP and IBM,and the partnership between SAP and IBM allows SAP users to exploit

this new technology immediately. For example, the latest versions of SAP andDB2 provide users more control over resource allocation and better support forperformance tuning.

The previous chapters have outlined the current benefits of the integrated SAPDBA Cockpit for DB2 LUW. In this chapter, you will see that these benefits con-tinue to grow as the SAP-DB2 partnership continues to mature.

Workload Management (WLM)DB2 9.5 includes new Workload Management (WLM) features that can ensureService Level Agreements (SLAs) are achieved for overall system performance.Using WLM, client requests are grouped into workloads defined in DB2, based

171

on connection attributes. These workloads are mapped to different serviceclasses, which define the resource limits, alert thresholds, and priorities of thoseworkloads within the database.

SAP Enhancement Package 1 for SAP NetWeaver 7.0 integrates DB2 9.5 Work-load Management into the SAP kernel. SAP delivers a predefined WLM configu-ration proposal, which defines workloads and service classes for each uniquework process type. This basic configuration can then be enhanced by creatingone additional workload and service class, which can prioritize work based onthe SAP user, SAP transaction, or SAP application server.

Workloads and Service ClassesConfiguration of the WLM settings is integrated into the DBA Cockpit, whichthen launches the Workloads and Service Classes content area in a webbrowser-based user interface, as shown in Figure 9.1. The Overview tab providesa graphical view of the workloads and their associated service classes. TheWorkloads tab displays the details of each workload, including service classmappings and workload status. The Service Classes tab (shown in Figure 9.1)displays the status of each service class, and its agent and pre-fetch priorities.

172

CHAPTER 9: New Features

Figure 9.1: Workloads and service classes from DB2 Workload Management are now inte-grated into SAP.

The service class priorities can be maintained within the General tab in the bot-tom half of the display. The Statistics tab contains detailed information andgraphical histograms displaying performance characteristics of the applicationsthat have run within that service class.

Critical ActivitiesThe Critical Activities screen, shown in Figure 9.2, provides an administrative in-terface for the thresholds defined for WLM. There is one area to maintain andconfigure thresholds for various database activities, and another to view histori-cal information on threshold violations.

The thresholds define the Service Level Agreements for the system. The thresh-old violations allow administrators to quickly identify performance problems re-lated to these SLAs, and then take measures to resolve any issues.

173


Figure 9.2: Threshold violations can be viewed within the Critical Activities screen.

Finally, the SAP WLM Setup Status provides an overview of the WLM configu-ration. This displays the status of the various WLM configuration steps, and dis-plays the areas of WLM that have been successfully set up.

BI AdministrationDB2 provides several key, unique features to improve the performance and man-ageability of large SAP NetWeaver BW data warehouses. Here are two of thesekey features:

• Database Partitioning Feature (DPF)—DPF allows large database tablesto be distributed across multiple database partitions, perhaps on multiplephysical servers. This can drastically improve performance andmanageability, because each partition only operates on the portion of thedata that is distributed on that partition.

• Multi-Dimensional Clustering (MDC)—MDC allows the rows of SAPNetWeaver BW objects to be clustered on disk by multiple key columns.Each data page on disk only contains rows for one unique combination ofMDC column values. Any query containing restrictions on any of thesecolumns only reads the data pages containing relevant rows, and every rowon those pages is relevant to the query. This drastically reduces I/O duringlarge BW reports, and can improve performance by orders of magnitude.

Due to the importance of these features, SAP has integrated DB2 DPF and MDCtooling into the DBA Cockpit, within a folder named either “BW Administra-tion” or “Wizards,” depending on the release of SAP being used.

BI Data DistributionDB2 table spaces are created in partition groups. When an SAP NetWeaver BWsystem is installed on a partitioned DB2 database, the objects in the BW tablespaces may be distributed across multiple database partitions. If a DBA changesthe partition layout (usually by adding partitions to the BW partition groups), thedata residing in those table spaces needs to be redistributed, so that the same

174


amount of data resides on each partition. This ensures that each partition hasnearly the same workload when processing large BW reports. For example, if apartition group with four partitions is altered to add two new partitions, the datapreviously distributed across the original four partitions must be redistributedacross all six partitions.

Data redistribution is an online utility. It is throttled by the UTIL_IMPACT_LIM da-tabase manager configuration parameter setting. However, it may require themovement of a large amount of data, and therefore, take a very long time to run.It is usually recommended that you redistribute data during a maintenance win-dow, or during low system usage.

There are several steps involved in changing the partitioning scheme of adatabase:

1. Alter the partition group(s) to add or remove partitions.

2. Create temporary table space containers on all new partitions.

3. Redistribute the existing data across the new partition layout.

The BW Data Distribution Wizard in the DBA Cockpit provides a very simpleinterface for this process, shown in Figure 9.3. First, you select the partitions foreach partition group from a grid of checkboxes. Next, the wizard defines tempo-rary table space containers, based on the default SAP container paths. Finally,you schedule the redistribution job to run during low system usage.

The wizard immediately alters the partition groups, creates the temporary tablespace containers, and schedules the redistribution job in the DBA Planning Cal-endar. Once the redistribution job completes, the partition layout changes aredone.

175


The MDC AdvisorAs mentioned earlier, DB2 Multi-Dimensional Clustering is a type of clusteredindex that can be created on SAP NetWeaver BW objects. MDC indexes point toextents rather than rows, and every row within an MDC extent contains the sameMDC column values. When large SAP NetWeaver BW reports are generated,MDC indexes can drastically reduce the number of pages read from disk, becauseeach page only contains rows for the requested values of the MDC indexedcolumns.

Creating proper MDC indexes can greatly improve SAP NetWeaver BW perfor-mance. However, finding the best columns for the MDC index on a BW objectcan be challenging. The MDC index will benefit performance most if its columnsare frequently used as query restrictions in the WHERE clause of many large BWqueries. Therefore, optimal MDC index selection requires you to search throughthe SQL cache for BW object queries, and identify the frequently used columns.Those columns will be the best candidates for MDC dimensions on that table.

176


Figure 9.3: The BI Data Distribution wizard guides users through the steps required to re-partition a DB2 SAP BW system.

Then, you must identify the cardinality (number of unique values) of each poten-tial MDC dimension. High-cardinality columns might not be desirable, becauseDB2 will allocate one extent for each unique combination of MDC index values.Therefore, if a unique index is included in the MDC index, each extent will onlycontain one row, resulting in wasted disk space. The best MDC index columnsare low-cardinality columns frequently used in query restrictions. This can im-prove performance without increasing table size.

DB2 contains several Advisors, which are able to assist you with some of themore intensive tasks. DB2 has both a traditional Index Advisor (discussed in theprevious chapter), and an MDC Index Advisor. The MDC Index Advisor collectsqueries run on selected tables, analyzes their characteristics, and recommends op-timal MDC indexes to improve performance without increasing disk consump-tion. This takes into account all queries run during the collection period, andgreatly reduces the effort involved in MDC index creation.

SAP Enhancement Package 1 for SAP NetWeaver 7.0 includes a graphical inter-face to the DB2 MDC Index Advisor in the DBA Cockpit, under BI Administra-tion�MDC Advisor. The Input tab, shown in Figure 9.4, contains methods forcollecting and analyzing queries for specific BW objects (InfoCube FACT tablesand the active table of DataStore Objects).

177


Figure 9.4:Add InfoProviders to the MDC Advisor, and let DB2 recom-mend beneficial MDC indexes.

The steps for query analysis are as follows:

1. Click the Add InfoProvider button to input the BW object(s) you wantto analyze.

2. Select one or more InfoProviders to analyze, and click the StartCollection button to begin collecting query information from thoseobjects.

3. Execute the BW reports that run on the objects being analyzed. Thequeries that execute against the selected BW objects will be stored indatabase tables in the SYSTOOLS table space.

4. After the reports finish, select the BW object(s) with a status ofRUNNING, and click the Stop Collection button to halt their collectionprocesses.

5. Select the BW object(s) to analyze, and click the Analyze button to startthe query analysis process. The analysis is scheduled as a backgroundjob, which can be monitored through the DBA Planning Calendar. Oncethe analysis job completes, the MDC Advisor displays the results anddeletes any saved BW temporary tables and query information.

The MDC proposals can be viewed in the Result tab, shown in Figure 9.5. Therecommended MDC index is listed beneath each analyzed InfoProvider, with es-timates for performance and space consumption. The Estimated Improvementgives the overall performance improvement expected for all queries on thatInfoProvider. The Estimated Space Increase specifies the percentage that theInfoProvider may increase in size. The MDC Advisor will only recommendMDC indexes with an estimated space increase of less than 10 percent. The pro-posed MDC indexes can then be implemented from transaction RSA1.

178


SummaryThese pages have presented countless examples of DB2 administration integratedinto the core SAP NetWeaver technology. SAP DBAs can perform almost anyDB2 administrative task through standard SAP transactions. This integration sim-plifies many SAP database administration tasks, and eases the transition fromother relational databases to DB2. The partnership between DB2 and SAP, andthe complete integration of DB2 into the DBA Cockpit, are two of the many rea-sons why DB2 is the preferred and recommended database for SAP systems.

The DBA Cockpit provides SAP database administrators a single interface for al-most all DB2 monitoring and administration, such as the following:

• Monitoring key performance indicators

• Space management and administration tasks

• Analysis of backup and recovery processes

• Changing DB2 configuration parameters

• Defining database partitions for SAP NetWeaver BW and redistributingdata

• Optimizing buffer pool memory allocation

• Configuring automatic RUNSTATs, REORGs, and backups

• Creating, scheduling, and monitoring both standard and custom databasejobs in the DBA Planning Calendar

179


Figure 9.5: The Results tab contains the MDC Indexes recommended by DB2.

• Monitoring CCMS database health alerts and thresholds

• Auditing DBACOCKPIT activity

• Performing consistency checks between SAP and DB2 metadata

• Executing SQL commands

• Analyzing optimizer access plans

• Recommending and testing traditional and MDC indexes

• Tracing database calls

• Viewing diagnostic log files

• Accessing the online DB2 Help Center

As IBM releases new DB2 technology, new features are continually integratedinto the SAP DBA Cockpit. This enables SAP database administrators to easilyexploit the new technology in their SAP systems.

To close with one final airline pilot analogy: fly the latest and greatest jet. Selectthe cockpit that allows you the most control to perfect the performance of youraircraft. Pilot the best technology, which is integrated completely and optimizedspecifically for your cockpit. Launch your SAP business systems into the futureon DB2.

180


DB2 is now the database most recommended for use with SAP applications, and DB2 skills are now critical for all SAP technical professionals. The most important tool within SAP for database administration is the SAP DBA Cockpit, which provides a more extensive administrative interface on DB2 than any other database. This book steps through every aspect of the SAP DBA Cockpit for DB2. Readers will quickly learn how to use the SAP DBA Cockpit to perform powerful DB2 administration tasks and performance analysis. This book provides both DB2 beginners and experts an invaluable reference for the abundance of information accessible from within the SAP DBA Cockpit for DB2. It makes it easy for SAP NetWeaver administrators, consultants, and DBAs to understand the strengths of DB2 for SAP, and how to leverage those strengths within their own unique application environments.

EDUARDO AKISUE

Certified DB2 9 Administrator

Certified Informix Administrator



JEREMY BROUGHTON

SAP Certified Basis Consultant for DB2 on NetWeaver 2004


IBM Certified DB2 9 Administrator

LIWEN YEOW

Certified Technology Associate–System Administration (DB2) for SAP NetWeaver 7.0

SAP Certified Technology Consultant for DB/OS Migration

PATRICK ZENG

Certified DB2 Solutions Expert


MC Press Online, LP125 N. Woodland TrailLewisville, TX 75077

SAP DBA COCKPITFlight Plans for DB2 LUW Database Administrators

sap dba cockpit - flight plans for db2 luw database administrators

Documents

strengths of db2

db2 beginners

db2 skills

sap applications

sap netweaver administrators

eduardo akisuecertified

sap technical professionals

database administration